<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html lang="en" dir="ltr">
<head>
<title>JSON-LD Syntax 1.0</title>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<!--
  === NOTA BENE ===
  For the three scripts below, if your spec resides on dev.w3 you can check them
  out in the same tree and use relative links so that they'll work offline,
  -->


<style>
.diff { font-weight:bold; color:#0a3; }
ol.algorithm.update { margin-left: 2em; }
ol.algorithm.update>li { list-style-type: none; }
ol.algorithm.update>li>span.list-number {
  display:block;
  float: left;
  margin-left: -3.5em;
}
</style>
<style type="text/css">
/*****************************************************************
 * ReSpec CSS
 * Robin Berjon (robin at berjon dot com)
 * v0.05 - 2009-07-31
 *****************************************************************/


/* --- INLINES --- */
em.rfc2119 { 
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  1px solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  1px dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

code {
    color:  #ff4500;
}


/* --- WEB IDL --- */
pre.idl {
    border-top: 1px solid #90b8de;
    border-bottom: 1px solid #90b8de;
    padding:    1em;
    line-height:    120%;
}

pre.idl::before {
    content:    "WebIDL";
    display:    block;
    width:      150px;
    background: #90b8de;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

.idlType {
    color:  #ff4500;
    font-weight:    bold;
    text-decoration:    none;
}

/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID, .idlDictionaryID {
    font-weight:    bold;
    color:  #005a9c;
}

.idlSuperclass {
    font-style: italic;
    color:  #005a9c;
}

/*.idlAttribute*/
.idlAttrType, .idlFieldType, .idlMemberType {
    color:  #005a9c;
}
.idlAttrName, .idlFieldName, .idlMemberName {
    color:  #ff4500;
}
.idlAttrName a, .idlFieldName a, .idlMemberName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlMethod*/
.idlMethType {
    color:  #005a9c;
}
.idlMethName {
    color:  #ff4500;
}
.idlMethName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlParam*/
.idlParamType {
    color:  #005a9c;
}
.idlParamName {
    font-style: italic;
}

.extAttr {
    color:  #666;
}

/*.idlConst*/
.idlConstType {
    color:  #005a9c;
}
.idlConstName {
    color:  #ff4500;
}
.idlConstName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlException*/
.idlExceptionID {
    font-weight:    bold;
    color:  #c00;
}

.idlTypedefID, .idlTypedefType {
    color:  #005a9c;
}

.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
    color:  #c00;
    font-weight:    normal;
}

.excName a {
    font-family:    monospace;
}

.idlRaises a.idlType, .excName a.idlType {
    border-bottom:  1px dotted #c00;
}

.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
    width:  45px;
    text-align: center;
}
.excGetSetTrue, .prmNullTrue, .prmOptTrue { color:  #0c0; }
.excGetSetFalse, .prmNullFalse, .prmOptFalse { color:  #c00; }

.idlImplements a {
    font-weight:    bold;
}

dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
    margin-left:    2em;
}

.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
    font-weight:    normal;
}

.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
    font-weight:    bold;
    color:  #000;
    font-family:    monospace;
}

.attributes dt code, .fields dt code, .dictionary-members dt code {
    background:  #ffffd2;
}

.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
    color:  #005a9c;
    background:  transparent;
    font-family:    inherit;
    font-weight:    normal;
    font-style: italic;
}

.methods dt code {
    background:  #d9e6f8;
}

.constants dt code {
    background:  #ddffd2;
}

.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
    margin-bottom:  1em;
}

table.parameters, table.exceptions {
    border-spacing: 0;
    border-collapse:    collapse;
    margin: 0.5em 0;
    width:  100%;
}
table.parameters { border-bottom:  1px solid #90b8de; }
table.exceptions { border-bottom:  1px solid #deb890; }

.parameters th, .exceptions th {
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
    font-family:    initial;
    font-weight:    normal;
    text-shadow:    #666 1px 1px 0;
}
.parameters th { background: #90b8de; }
.exceptions th { background: #deb890; }

.parameters td, .exceptions td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
    vertical-align: top;
}

.parameters tr:first-child td, .exceptions tr:first-child td {
    border-top: none;
}

.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
    width:  100px;
}

.parameters td.prmType {
    width:  120px;
}

table.exceptions table {
    border-spacing: 0;
    border-collapse:    collapse;
    width:  100%;
}

/* --- TOC --- */
.toc a {
    text-decoration:    none;
}

a .secno {
    color:  #000;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}

/* --- EXAMPLES --- */
pre.example {
    border-top: 1px solid #ff4500;
    border-bottom: 1px solid #ff4500;
    padding:    1em;
    margin-top: 1em;
}

pre.example::before {
    content:    "Example";
    display:    block;
    width:      150px;
    background: #ff4500;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

/* --- EDITORIAL NOTES --- */
.issue {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #ffc;
}

.issue::before {
    content:    "Issue";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.note {
    margin: 1em 0em 0em;
    padding:    1em;
    border: 2px solid #cff6d9;
    background: #e2fff0;
}

.note::before {
    content:    "Note";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #cff6d9;
    background: #fff;
    padding:    3px 1em;
}

/* --- Best Practices --- */
div.practice {
    border: solid #bebebe 1px;
    margin: 2em 1em 1em 2em;
}

span.practicelab {
    margin: 1.5em 0.5em 1em 1em;
    font-weight: bold;
    font-style: italic;
}

span.practicelab   { background: #dfffff; }

span.practicelab {
    position: relative;
    padding: 0 0.5em;
    top: -1.5em;
}

p.practicedesc {
    margin: 1.5em 0.5em 1em 1em;
}

@media screen {
    p.practicedesc {
        position: relative;
        top: -2em;
        padding: 0;
        margin: 1.5em 0.5em -1em 1em;
    }
}

/* --- SYNTAX HIGHLIGHTING --- */
pre.sh_sourceCode {
  background-color: white;
  color: black;
  font-style: normal;
  font-weight: normal;
}

pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; }           /* language keywords */
pre.sh_sourceCode .sh_type { color: #666; }                            /* basic types */
pre.sh_sourceCode .sh_usertype { color: teal; }                             /* user defined types */
pre.sh_sourceCode .sh_string { color: red; font-family: monospace; }        /* strings and chars */
pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; }     /* regular expressions */
pre.sh_sourceCode .sh_specialchar { color: 	#ffc0cb; font-family: monospace; }  /* e.g., \n, \t, \\ */
pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; }         /* comments */
pre.sh_sourceCode .sh_number { color: purple; }                             /* literal numbers */
pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; }       /* e.g., #include, import */
pre.sh_sourceCode .sh_symbol { color: blue; }                            /* e.g., *, + */
pre.sh_sourceCode .sh_function { color: black; font-weight: bold; }         /* function calls and declarations */
pre.sh_sourceCode .sh_cbracket { color: red; }                              /* block brackets (e.g., {, }) */
pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; }   /* TODO and FIXME */

/* Predefined variables and functions (for instance glsl) */
pre.sh_sourceCode .sh_predef_var { color: #00008B; }
pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }

/* for OOP */
pre.sh_sourceCode .sh_classname { color: teal; }

/* line numbers (not yet implemented) */
pre.sh_sourceCode .sh_linenum { display: none; }

/* Internet related */
pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }

/* for ChangeLog and Log files */
pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }

/* for Prolog, Perl... */
pre.sh_sourceCode .sh_variable { color: #006400; }

/* for LaTeX */
pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
pre.sh_sourceCode .sh_argument { color: #006400; }
pre.sh_sourceCode .sh_optionalargument { color: purple; }
pre.sh_sourceCode .sh_math { color: orange; }
pre.sh_sourceCode .sh_bibtex { color: blue; }

/* for diffs */
pre.sh_sourceCode .sh_oldfile { color: orange; }
pre.sh_sourceCode .sh_newfile { color: #006400; }
pre.sh_sourceCode .sh_difflines { color: blue; }

/* for css */
pre.sh_sourceCode .sh_selector { color: purple; }
pre.sh_sourceCode .sh_property { color: blue; }
pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }

/* other */
pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }

</style><style type="text/css">ol.algorithm { counter-reset:numsection; list-style-type: none; }
ol.algorithm li { margin: 0.5em 0; }
ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; }

</style><link href="http://www.w3.org/StyleSheets/TR/w3c-unofficial" rel="stylesheet" type="text/css" charset="utf-8"><style type='text/css'>
.diff-old-a {
  font-size: smaller;
  color: red;
}

.diff-new { background-color: yellow; }
.diff-chg { background-color: lime; }
.diff-new:before,
.diff-new:after
    { content: "\2191" }
.diff-chg:before, .diff-chg:after
    { content: "\2195" }
.diff-old { text-decoration: line-through; background-color: #FBB; }
.diff-old:before,
.diff-old:after
    { content: "\2193" }
:focus { border: thin red solid}
</style>
</head>


<body style="display: inherit; ">
<div class="head">
<p>
</p>
<h1 class="title" id="title">
JSON-LD
Syntax
1.0
</h1>
<h2 id="subtitle">
A
Context-based
JSON
Serialization
for
Linking
Data
</h2>
<h2 id="unofficial-draft-12-january-2012">
Unofficial
Draft
<del class="diff-old">24
October
2011
</del>
<ins class="diff-chg">12
January
2012
</ins>
</h2>
<dl>
<dt>
<del class="diff-old">Editor:
</del>
<ins class="diff-chg">Editors:
</ins>
</dt>
<dd>
<a href="http://manu.sporny.org/">
Manu
Sporny
</a>,
<a href="http://digitalbazaar.com/">
Digital
Bazaar
</a>
</dd>
<dd>
<a href="http://greggkellogg.net/">
<ins class="diff-new">Gregg
Kellogg
</ins></a>,<a href="http://kellogg-assoc.com/"><ins class="diff-new">
Kellogg
Associates
</ins></a></dd>
<dt>
Authors:
</dt>
<dd>
<a href="http://digitalbazaar.com/">
Manu
Sporny
</a>,
<a href="http://digitalbazaar.com/">
Digital
Bazaar
</a>
</dd>
<dd>
<a href="http://digitalbazaar.com/">
Dave
Longley
</a>,
<a href="http://digitalbazaar.com/">
Digital
Bazaar
</a>
</dd>
<dd>
<a href="http://greggkellogg.net/">
Gregg
Kellogg
</a>,
<a href="http://kellogg-assoc.com/">
Kellogg
Associates
</a>
</dd>
<dd>
<a href="http://www.markus-lanthaler.com/">
Markus
Lanthaler
</a>,
<a href="http://www.tugraz.at/">
Graz
University
of
Technology
</a>
</dd>
<dd>
<a href="http://webbackplane.com/">
Mark
Birbeck
</a>,
<a href="http://webbackplane.com/">
Backplane
Ltd.
</a>
</dd>
</dl>
<p>
This
document
is
also
available
in
this
non-normative
format:
<a href="diff-20111023.html">
diff
to
previous
version
</a>.
</p>
<p class="copyright">
This
document
is
licensed
under
a
<a class="subfoot" href="http://creativecommons.org/licenses/by/3.0/" rel="license">
Creative
Commons
Attribution
3.0
License
</a>.
</p>
<hr>
</div>
<div id="abstract" class="introductory section">
<h2>
Abstract
</h2>
<p>
JSON
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RFC4627">
RFC4627
</a>
</cite>
]
has
proven
to
be
a
highly
useful
object
serialization
and
messaging
format.
In
an
attempt
to
harmonize
the
representation
of
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
in
JSON,
this
specification
outlines
a
common
JSON
representation
format
for
expressing
directed
graphs;
mixing
both
Linked
Data
and
non-Linked
Data
in
a
single
document.
</p>
</div>
<div id="sotd" class="introductory section">
<h2>
Status
of
This
Document
</h2>
<p>
This
document
is
merely
a
public
working
draft
of
a
potential
specification.
It
has
no
official
standing
of
any
kind
and
does
not
represent
the
support
or
consensus
of
any
standards
organisation.
</p>
<p>
This
document
is
an
experimental
work
in
progress.
</p>
</div>
<div id="toc" class="section">
<h2 class="introductory">
Table
of
Contents
</h2>
<ul class="toc">
<li class="tocline">
<a href="#introduction" class="tocxref">
<span class="secno">
1.
</span>
Introduction
</a>
<ul class="toc">
<li class="tocline">
<a href="#how-to-read-this-document" class="tocxref">
<span class="secno">
1.1
</span>
How
to
Read
this
Document
</a>
</li>
<li class="tocline">
<a href="#syntax-tokens-and-keywords" class="tocxref">
<span class="secno">
1.2
</span>
Syntax
Tokens
and
Keywords
</a>
</li>
<li class="tocline">
<a href="#contributing" class="tocxref">
<span class="secno">
1.3
</span>
Contributing
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#design" class="tocxref">
<span class="secno">
2.
</span>
Design
</a>
<ul class="toc">
<li class="tocline">
<a href="#goals-and-rationale" class="tocxref">
<span class="secno">
2.1
</span>
Goals
and
Rationale
</a>
</li>
<li class="tocline">
<del class="diff-old">2.2
Linked
Data
</del>
<a href="#linking-data" class="tocxref">
<span class="secno">
<del class="diff-old">2.3
</del>
<ins class="diff-chg">2.2
</ins>
</span>
Linking
Data
</a>
</li>
<li class="tocline">
<a href="#the-context" class="tocxref">
<span class="secno">
<del class="diff-old">2.4
</del>
<ins class="diff-chg">2.3
</ins>
</span>
The
Context
</a>
<del class="diff-old">2.4.1
External
Contexts
</del>
</li>
<li class="tocline">
<a href="#from-json-to-json-ld" class="tocxref">
<span class="secno">
<del class="diff-old">2.5
</del>
<ins class="diff-chg">2.4
</ins>
</span>
From
JSON
to
JSON-LD
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#basic-concepts" class="tocxref">
<span class="secno">
3.
</span>
Basic
Concepts
</a>
<ul class="toc">
<li class="tocline">
<a href="#iris" class="tocxref">
<span class="secno">
3.1
</span>
IRIs
</a>
</li>
<li class="tocline">
<a href="#identifying-the-subject" class="tocxref">
<span class="secno">
3.2
</span>
Identifying
the
Subject
</a>
</li>
<li class="tocline">
<a href="#specifying-the-type" class="tocxref">
<span class="secno">
3.3
</span>
Specifying
the
Type
</a>
</li>
<li class="tocline">
<a href="#strings" class="tocxref">
<span class="secno">
3.4
</span>
Strings
</a>
</li>
<li class="tocline">
<a href="#string-internationalization" class="tocxref">
<span class="secno">
3.5
</span>
String
Internationalization
</a>
</li>
<li class="tocline">
<a href="#typed-literals" class="tocxref">
<span class="secno">
3.6
</span>
Typed
Literals
</a>
</li>
<li class="tocline">
<a href="#multiple-objects-for-a-single-property" class="tocxref">
<span class="secno">
3.7
</span>
Multiple
Objects
for
a
Single
Property
</a>
</li>
<li class="tocline">
<a href="#multiple-literals-for-a-single-property" class="tocxref">
<span class="secno">
3.8
</span>
Multiple
<del class="diff-old">Typed
</del>
Literals
for
a
Single
Property
</a>
</li>
<li class="tocline">
<a href="#rdf-collection" class="tocxref">
<span class="secno">
3.9
</span>
Lists
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#advanced-concepts" class="tocxref">
<span class="secno">
4.
</span>
Advanced
Concepts
</a>
<ul class="toc">
<li class="tocline">
<a href="#external-contexts" class="tocxref">
<span class="secno">
4.1
</span>
<del class="diff-old">Base
URI
</del>
<ins class="diff-chg">External
Contexts
</ins>
</a>
</li>
<li class="tocline">
<a href="#expanded-term-definition" class="tocxref">
<span class="secno">
4.2
</span>
<del class="diff-old">Default
Vocabulary
</del>
<ins class="diff-chg">Expanded
Term
Definition
</ins>
</a>
</li>
<li class="tocline">
<a href="#default-language" class="tocxref">
<span class="secno">
4.3
</span>
Default
Language
</a>
</li>
<li class="tocline">
<a href="#prefixes" class="tocxref">
<span class="secno">
4.4
</span>
<del class="diff-old">Vocabulary
</del>
Prefixes
</a>
</li>
<li class="tocline">
<a href="#iri-expansion-within-context" class="tocxref">
<span class="secno">
4.5
</span>
<abbr title="Internationalized Resource Identifier">
<ins class="diff-new">IRI
</ins></abbr><ins class="diff-new">
Expansion
within
Context
</ins></a></li><li class="tocline"><a href="#automatic-typing" class="tocxref"><span class="secno"><ins class="diff-new">
4.6
</ins></span>
Automatic
Typing
</a>
</li>
<li class="tocline">
<a href="#type-coercion" class="tocxref">
<span class="secno">
<del class="diff-old">4.6
</del>
<ins class="diff-chg">4.7
</ins>
</span>
Type
Coercion
</a>
</li>
<li class="tocline">
<a href="#chaining" class="tocxref">
<span class="secno">
<del class="diff-old">4.7
</del>
<ins class="diff-chg">4.8
</ins>
</span>
Chaining
</a>
</li>
<li class="tocline">
<a href="#identifying-unlabeled-nodes" class="tocxref">
<span class="secno">
<del class="diff-old">4.8
</del>
<ins class="diff-chg">4.9
</ins>
</span>
Identifying
Unlabeled
Nodes
</a>
</li>
<li class="tocline">
<a href="#aliasing-keywords" class="tocxref">
<span class="secno">
<del class="diff-old">4.9
</del>
<ins class="diff-chg">4.10
</ins>
</span>
Aliasing
Keywords
</a>
</li>
</ul>
</li>
<li class="tocline">
<del class="diff-old">5.
Using
JSON-LD
for
RDF
</del>
<a href="#markup-examples" class="tocxref">
<span class="secno">
A.
</span>
Markup
Examples
</a>
<ul class="toc">
<li class="tocline">
<a href="#turtle" class="tocxref">
<span class="secno">
A.1
</span>
Turtle
</a>
<ul class="toc">
<li class="tocline">
<a href="#prefix-definitions" class="tocxref">
<span class="secno">
A.1.1
</span>
Prefix
<del class="diff-old">and
Base
</del>
definitions
</a>
</li>
<li class="tocline">
<a href="#chaining-1" class="tocxref">
<span class="secno">
A.1.2
</span>
Chaining
</a>
</li>
<li class="tocline">
<a href="#lists" class="tocxref">
<span class="secno">
A.1.3
</span>
Lists
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#rdfa" class="tocxref">
<span class="secno">
A.2
</span>
RDFa
</a>
</li>
<li class="tocline">
<a href="#microformats" class="tocxref">
<span class="secno">
A.3
</span>
Microformats
</a>
</li>
<li class="tocline">
<a href="#microdata" class="tocxref">
<span class="secno">
A.4
</span>
Microdata
</a>
</li>
</ul>
</li>
<li class="tocline">
<a href="#linked-data" class="tocxref">
<span class="secno">
B.
</span>
<ins class="diff-new">Linked
Data
</ins></a></li><li class="tocline"><a href="#mashing-up-vocabularies" class="tocxref"><span class="secno"><ins class="diff-new">
C.
</ins></span>
Mashing
Up
Vocabularies
</a>
</li>
<li class="tocline">
<a href="#iana-considerations" class="tocxref">
<span class="secno">
<del class="diff-old">C.
</del>
<ins class="diff-chg">D.
</ins>
</span>
IANA
Considerations
</a>
</li>
<li class="tocline">
<a href="#acknowledgements" class="tocxref">
<span class="secno">
<del class="diff-old">D.
</del>
<ins class="diff-chg">E.
</ins>
</span>
Acknowledgements
</a>
</li>
<li class="tocline">
<a href="#references" class="tocxref">
<span class="secno">
<del class="diff-old">E.
</del>
<ins class="diff-chg">F.
</ins>
</span>
References
</a>
<ul class="toc">
<li class="tocline">
<a href="#normative-references" class="tocxref">
<span class="secno">
<del class="diff-old">E.1
</del>
<ins class="diff-chg">F.1
</ins>
</span>
Normative
references
</a>
</li>
<li class="tocline">
<a href="#informative-references" class="tocxref">
<span class="secno">
<del class="diff-old">E.2
</del>
<ins class="diff-chg">F.2
</ins>
</span>
Informative
references
</a>
</li>
</ul>
</li>
</ul>
</div>
<div id="introduction" class="section">
<h2>
<span class="secno">
1.
</span>
Introduction
</h2>
<p>
JSON,
as
specified
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RFC4627">
RFC4627
</a>
</cite>
],
is
a
simple
language
for
representing
data
on
the
Web.
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
is
a
technique
for
creating
a
graph
of
interlinked
data
across
different
documents
or
Web
sites.
Data
entities
are
described
using
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s,
which
are
typically
dereferencable
and
thus
may
be
used
to
find
more
information
about
an
entity,
creating
a
<del class="diff-old">&quot;Web
</del>
<ins class="diff-chg">"Web
</ins>
of
<del class="diff-old">Knowledge&quot;.
</del>
<ins class="diff-chg">Knowledge".
</ins>
JSON-LD
is
intended
to
be
a
simple
publishing
method
for
expressing
not
only
Linked
Data
in
JSON,
but
also
for
adding
semantics
to
existing
JSON.
</p>
<p>
JSON-LD
is
designed
as
a
<del class="diff-old">light-weight
</del>
<ins class="diff-chg">lightweight
</ins>
syntax
that
can
be
used
to
express
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>.
It
is
primarily
intended
to
be
a
way
to
use
Linked
Data
in
Javascript
and
other
Web-based
programming
environments.
It
is
also
useful
when
building
interoperable
Web
services
and
when
storing
Linked
Data
in
JSON-based
document
storage
engines.
It
is
practical
and
designed
to
be
as
simple
as
possible,
utilizing
the
large
number
of
JSON
parsers
and
libraries
available
today.
<del class="diff-old">It
is
designed
to
be
able
to
express
key-value
pairs,
RDF
data,
RDFa
[
RDFA-CORE
]
data,
Microformats
[
MICROFORMATS
]
data,
and
Microdata
[
MICRODATA
].
That
is,
it
supports
every
major
Web-based
structured
data
model
in
use
today.
</del>
</p>
<p>
The
syntax
does
not
necessarily
require
applications
to
change
their
JSON,
but
allows
to
easily
add
meaning
by
<ins class="diff-new">simply
</ins>
adding
<del class="diff-old">context
in
a
way
that
is
either
in-band
</del>
or
<del class="diff-old">out-of-band.
</del>
<ins class="diff-chg">referencing
a
context.
</ins>
The
syntax
is
designed
to
not
disturb
already
deployed
systems
running
on
JSON,
but
provide
a
smooth
upgrade
path
from
JSON
to
<del class="diff-old">JSON
</del>
<ins class="diff-chg">JSON-LD
</ins>
with
added
semantics.
Finally,
the
format
is
intended
to
be
easy
to
parse,
efficient
to
generate,
<del class="diff-old">convertible
to
RDF
in
one
pass,
</del>
and
<ins class="diff-new">to
</ins>
require
a
very
small
memory
footprint
in
order
to
operate.
</p>
<div id="how-to-read-this-document" class="section">
<h3>
<span class="secno">
1.1
</span>
How
to
Read
this
Document
</h3>
<p>
This
document
is
a
detailed
specification
for
a
serialization
of
Linked
Data
in
JSON.
The
document
is
primarily
intended
for
the
following
audiences:
</p>
<ul>
<li>
<del class="diff-old">Web
developers
that
want
to
understand
the
design
decisions
and
language
syntax
for
JSON-LD.
</del>
Software
developers
that
want
to
encode
<del class="diff-old">Microformats,
RDFa,
or
Microdata
</del>
<ins class="diff-chg">Linked
Data
</ins>
in
a
way
that
is
cross-language
compatible
via
JSON.
</li>
<li>
Software
developers
that
want
to
<ins class="diff-new">understand
the
design
decisions
and
language
syntax
for
JSON-LD.
</ins></li><li><ins class="diff-new">
Software
developers
that
want
to
</ins>
implement
processors
and
APIs
for
JSON-LD.
</li>
</ul>
<p>
This
specification
does
not
describe
the
processing
algorithms
and
programming
interfaces,
for
those
see
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-JSON-LD-API">
JSON-LD-API
</a>
</cite>
].
</p>
<p>
To
understand
the
basics
in
this
specification
you
must
first
be
familiar
with
JSON,
which
is
detailed
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RFC4627">
RFC4627
</a>
</cite>
].
To
understand
the
API
and
how
it
is
intended
to
operate
in
a
programming
environment,
it
is
useful
to
have
working
knowledge
of
the
JavaScript
programming
language
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-ECMA-262">
ECMA-262
</a>
</cite>
]
and
WebIDL
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-WEBIDL">
WEBIDL
</a>
</cite>
].
<del class="diff-old">To
understand
how
JSON-LD
maps
to
RDF,
it
is
helpful
to
be
familiar
with
the
basic
RDF
concepts
[
RDF-CONCEPTS
].
</del>
</p>
<p>
<del class="diff-old">Examples
may
contain
references
to
existing
vocabularies
and
use
prefix
es
to
refer
to
Web
Vocabularies.
The
following
is
a
list
of
all
vocabularies
and
their
prefix
abbreviations,
as
used
in
this
document:
The
Dublin
Core
vocabulary
(abbreviation:
dc
,
e.g.,
dc:title
)
The
Friend
of
a
Friend
vocabulary
(abbreviation:
foaf
,
e.g.,
foaf:knows
)
The
RDF
vocabulary
(abbreviation:
rdf
,
e.g.,
rdf:type
)
The
XSD
vocabulary
(abbreviation:
xsd
,
e.g.,
xsd:integer
)
</del>
JSON
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RFC4627">
RFC4627
</a>
</cite>
]
defines
several
terms
which
are
used
throughout
this
document:
</p>
<dl>
<dt>
<dfn title="json_object" id="dfn-json_object">
JSON
Object
</dfn>
</dt>
<dd>
An
object
structure
is
represented
as
a
pair
of
curly
brackets
surrounding
zero
or
more
name/value
pairs
(or
members).
A
name
is
a
<a class="tref internalDFN" title="string" href="#dfn-string">
string
</a>.
A
single
colon
comes
after
each
name,
separating
the
name
from
the
value.
A
single
comma
separates
a
value
from
a
following
name.
The
names
within
an
object
<em class="rfc2119" title="should">
should
</em>
be
unique.
</dd>
<dt>
<dfn title="array" id="dfn-array">
array
</dfn>
</dt>
<dd>
An
array
is
an
ordered
collection
of
values.
An
array
structure
is
represented
as
square
brackets
surrounding
zero
or
more
values
(or
elements).
Elements
are
separated
by
commas.
Within
JSON-LD,
array
order
is
not
preserved
by
default,
unless
specific
markup
is
provided
(see
<a href="#rdf-collection">
Lists
</a>
).
This
is
because
the
basic
data
model
of
JSON-LD
is
a
<a class="tref internalDFN" title="linked_data_graph" href="#dfn-linked_data_graph">
linked
data
graph
</a>,
which
is
inherently
unordered.
</dd>
<dt>
<dfn title="string" id="dfn-string">
string
</dfn>
</dt>
<dd>
A
string
is
a
sequence
of
zero
or
more
Unicode
characters,
wrapped
in
double
quotes,
using
backslash
escapes.
A
character
is
represented
as
a
single
character
string.
</dd>
<dt>
<dfn title="number" id="dfn-number">
number
</dfn>
</dt>
<dd>
A
number
is
is
similar
to
that
used
in
most
programming
languages,
except
that
the
octal
and
hexadecimal
formats
are
not
used
and
that
leading
zeros
are
not
allowed.
</dd>
<dt>
<dfn title="true" id="dfn-true">
true
</dfn>
and
<dfn title="false" id="dfn-false">
false
</dfn>
</dt>
<dd>
Boolean
values.
</dd>
<dt>
<dfn title="null" id="dfn-null">
null
</dfn>
</dt>
<dd>
The
use
of
the
<em>
null
</em>
value
is
undefined
within
JSON-LD.
<div class="issue">
Supporting
<em>
null
</em>
in
JSON-LD
might
have
a
number
of
advantages
and
should
be
evaluated.
This
is
currently
an
<a href="https://github.com/json-ld/json-ld.org/issues/11">
open
issue
</a>.
</div>
</dd>
</dl>
<p>
</p>
</div>
<div id="syntax-tokens-and-keywords" class="section">
<h3>
<span class="secno">
1.2
</span>
Syntax
Tokens
and
Keywords
</h3>
<p>
JSON-LD
specifies
a
number
of
syntax
tokens
and
keywords
that
are
using
in
all
algorithms
described
in
this
section:
</p>
<dl>
<dt>
<code>
@context
</code>
</dt>
<dd>
Used
to
set
the
<a class="tref internalDFN" title="local_context" href="#dfn-local_context">
local
context
</a>.
</dd>
<dt>
<code>
<del class="diff-old">@base
</del>
<ins class="diff-chg">@id
</ins>
</code>
</dt>
<dd>
<del class="diff-old">Used
to
set
the
base
IRI
for
all
object
IRIs
affected
by
</del>
<ins class="diff-chg">Sets
</ins>
the
active
<del class="diff-old">context
.
</del>
<ins class="diff-chg">subject.
</ins>
</dd>
<dt>
<code>
<del class="diff-old">@vocab
</del>
<ins class="diff-chg">@language
</ins>
</code>
</dt>
<dd>
Used
to
<del class="diff-old">set
</del>
<ins class="diff-chg">specify
</ins>
the
<del class="diff-old">base
IRI
</del>
<ins class="diff-chg">language
</ins>
for
<del class="diff-old">all
property
IRIs
affected
by
the
active
context
.
@coerce
Used
to
specify
type
coercion
rules.
@literal
Used
to
specify
</del>
a
<del class="diff-old">literal
value.
@iri
Used
to
specify
an
IRI
value.
</del>
<ins class="diff-chg">literal.
</ins>
</dd>
<dt>
<code>
<del class="diff-old">@language
</del>
<ins class="diff-chg">@type
</ins>
</code>
</dt>
<dd>
Used
to
<del class="diff-old">specify
</del>
<ins class="diff-chg">set
</ins>
the
<del class="diff-old">language
for
</del>
<ins class="diff-chg">type
of
the
active
subject
or
the
datatype
of
</ins>
a
literal.
</dd>
<dt>
<code>
<del class="diff-old">@datatype
</del>
<ins class="diff-chg">@value
</ins>
</code>
</dt>
<dd>
Used
to
specify
the
<del class="diff-old">datatype
for
</del>
<ins class="diff-chg">value
of
</ins>
a
literal.
</dd>
<dt>
<code>:
</code>
</dt>
<dd>
The
separator
for
JSON
keys
and
values
that
use
the
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>
mechanism.
</dd>
<del class="diff-old">@subject
Sets
the
active
subject.
@type
Used
to
set
the
type
of
the
active
subject.
</del>
</dl>
</div>
<div id="contributing" class="section">
<h3>
<span class="secno">
1.3
</span>
Contributing
</h3>
<p>
There
are
a
number
of
ways
that
one
may
participate
in
the
development
of
this
specification:
</p>
<ul>
<li>
Technical
discussion
typically
occurs
on
the
public
mailing
list:
<a href="http://lists.w3.org/Archives/Public/public-linked-json/">
public-linked-json@w3.org
</a>
</li>
<li>
<a href="http://json-ld.org/minutes/">
Public
teleconferences
</a>
are
held
on
Tuesdays
at
1500UTC
on
the
second
and
fourth
week
of
each
month.
</li>
<li>
Specification
bugs
and
issues
should
be
reported
in
the
<a href="https://github.com/json-ld/json-ld.org/issues">
issue
tracker
</a>.
</li>
<li>
<a href="https://github.com/json-ld/json-ld.org/tree/main/spec">
Source
code
</a>
for
the
specification
can
be
found
on
Github.
</li>
<li>
The
<a href="http://webchat.freenode.net/?channels=#json-ld">
#json-ld
</a>
IRC
channel
is
available
for
real-time
discussion
on
irc.freenode.net.
</li>
</ul>
</div>
</div>
<div id="design" class="section">
<h2>
<span class="secno">
2.
</span>
Design
</h2>
<p>
The
following
section
outlines
the
design
goals
and
rationale
behind
the
JSON-LD
markup
language.
</p>
<div id="goals-and-rationale" class="section">
<h3>
<span class="secno">
2.1
</span>
Goals
and
Rationale
</h3>
<p>
A
number
of
design
considerations
were
explored
during
the
creation
of
this
markup
language:
</p>
<dl>
<dt>
Simplicity
</dt>
<dd>
Developers
need
only
know
JSON
and
three
keywords
to
use
the
basic
functionality
in
JSON-LD.
No
extra
processors
or
software
libraries
are
necessary
to
use
JSON-LD
in
its
most
basic
form.
The
language
attempts
to
ensure
that
developers
have
an
easy
learning
curve.
</dd>
<dt>
Compatibility
</dt>
<dd>
The
JSON-LD
markup
must
be
100%
compatible
with
JSON.
This
ensures
that
all
of
the
standard
JSON
libraries
work
seamlessly
with
JSON-LD
documents.
</dd>
<dt>
Expressiveness
</dt>
<dd>
The
syntax
must
be
able
to
express
directed
graphs,
which
have
been
proven
to
be
able
to
simply
express
almost
every
real
world
data
model.
</dd>
<dt>
Terseness
</dt>
<dd>
The
JSON-LD
syntax
must
be
very
terse
and
human
readable,
requiring
as
little
as
possible
effort
from
the
developer.
</dd>
<dt>
Zero
Edits,
most
of
the
time
</dt>
<dd>
JSON-LD
provides
a
mechanism
that
allows
developers
to
specify
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
in
a
way
that
is
out-of-band.
This
allows
organizations
that
have
already
deployed
large
JSON-based
infrastructure
to
add
meaning
to
their
JSON
documents
in
a
way
that
is
not
disruptive
to
their
day-to-day
operations
and
is
transparent
to
their
current
customers.
At
times,
mapping
JSON
to
a
graph
representation
can
become
difficult.
In
these
instances,
rather
than
having
JSON-LD
support
esoteric
markup,
we
chose
not
to
support
the
use
case
and
support
a
simplified
syntax
instead.
So,
while
Zero
Edits
is
a
goal,
it
is
not
always
possible
without
adding
great
complexity
to
the
language.
</dd>
<dt>
One-pass
Processing
</dt>
<dd>
JSON-LD
supports
one-pass
processing,
which
results
in
a
very
small
memory
footprint
when
processing
documents.
For
example,
to
<del class="diff-old">convert
</del>
<ins class="diff-chg">expand
</ins>
a
JSON-LD
document
<del class="diff-old">into
an
RDF
document
of
any
kind,
</del>
<ins class="diff-chg">from
a
compacted
form,
</ins>
only
one
pass
is
required
over
the
data.
</dd>
</dl>
</div>
<del class="diff-old">2.2
Linked
Data
The
following
definition
for
Linked
Data
is
the
one
that
will
be
used
for
this
specification.
Linked
Data
is
a
set
of
documents,
each
containing
a
representation
of
a
linked
data
graph.
A
linked
data
graph
is
an
unordered
labeled
directed
graph,
where
nodes
are
subject
s
or
object
s,
and
edges
are
properties.
A
subject
is
any
node
in
a
linked
data
graph
with
at
least
one
outgoing
edge.
A
subject
should
be
labeled
with
an
IRI
(an
Internationalized
Resource
Identifier
as
described
in
[
RFC3987
]).
An
object
is
a
node
in
a
linked
data
graph
with
at
least
one
incoming
edge.
An
object
may
be
labeled
with
an
IRI
.
An
object
may
be
a
subject
and
object
at
the
same
time.
A
property
is
an
edge
of
the
linked
data
graph
.
A
property
should
be
labeled
with
an
IRI
.
An
IRI
that
is
a
label
in
a
linked
data
graph
should
be
dereferencable
to
a
Linked
Data
document
describing
the
labeled
subject
,
object
or
property
.
A
literal
is
an
object
with
a
label
that
is
not
an
IRI
Note
that
the
definition
for
Linked
Data
above
is
silent
on
the
topic
of
unlabeled
nodes.
Unlabeled
nodes
are
not
considered
Linked
Data
.
However,
this
specification
allows
for
the
expression
of
unlabled
nodes,
as
most
graph-based
data
sets
on
the
Web
contain
a
number
of
associated
nodes
that
are
not
named
and
thus
are
not
directly
de-referenceable.
</del>
<div id="linking-data" class="section">
<h3>
<span class="secno">
<del class="diff-old">2.3
</del>
<ins class="diff-chg">2.2
</ins>
</span>
Linking
Data
</h3>
<p>
An
Internationalized
Resource
Identifier
(
<dfn title="iri" id="dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</dfn>
),
as
described
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RFC3987">
RFC3987
</a>
</cite>
],
is
a
mechanism
for
representing
unique
identifiers
on
the
web.
In
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>,
an
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
is
commonly
used
for
expressing
a
<a class="tref internalDFN" title="subject" href="#dfn-subject">
subject
</a>,
a
<a class="tref internalDFN" title="property" href="#dfn-property">
property
</a>
or
an
<a class="tref internalDFN" title="object" href="#dfn-object">
object
</a>.
</p>
<p>
JSON-LD
defines
a
mechanism
to
map
JSON
terms,
i.e.,
keys
and
values,
to
IRIs.
This
does
not
mean
that
JSON-LD
requires
every
key
or
value
to
be
an
<del class="diff-old">IRI,
</del>
<abbr title="Internationalized Resource Identifier">
<ins class="diff-chg">IRI
</ins></abbr>,
but
rather
ensures
that
keys
and
values
can
be
mapped
to
IRIs
if
the
developer
desires
to
transform
their
data
into
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>.
There
are
a
few
techniques
that
can
ensure
that
developers
will
generate
good
Linked
Data
for
the
Web.
JSON-LD
formalizes
those
techniques.
</p>
<p>
We
will
be
using
the
following
JSON
markup
as
the
example
for
the
rest
of
this
section:
</p>
<del class="diff-old">{
  &quot;name&quot;: &quot;Manu Sporny&quot;,
  &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
</del>
<pre class="example">{
<ins class="diff-chg">  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "avatar": "http://twitter.com/account/profile_image/manusporny"
</ins>
}
</pre>
</div>
<div id="the-context" class="section">
<h3>
<span class="secno">
<del class="diff-old">2.4
</del>
<ins class="diff-chg">2.3
</ins>
</span>
The
Context
</h3>
<p>
In
JSON-LD,
a
<dfn title="context" id="dfn-context">
context
</dfn>
is
used
to
map
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
s,
i.e.,
keys
<del class="diff-old">and
</del>
<ins class="diff-chg">with
associated
</ins>
values
in
an
JSON
document,
to
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s.
A
<dfn title="term" id="dfn-term">
term
</dfn>
is
a
short
word
that
<em class="rfc2119" title="may">
may
</em>
be
expanded
to
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>.
<ins class="diff-new">A
</ins><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-new">
term
</ins></a><em class="rfc2119" title="must"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
have
the
lexical
form
of
</ins><cite><a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/#NT-NCName"><ins class="diff-new">
NCName
</ins></a></cite><ins class="diff-new">
(see
[
</ins><cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES"><ins class="diff-new">
XML-NAMES
</ins></a></cite><ins class="diff-new">
]),
or
be
an
empty
string.
</ins></p><p>
The
Web
uses
IRIs
for
unambiguous
identification.
The
idea
is
that
these
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
s
mean
something
that
may
be
of
use
to
other
developers
and
that
it
is
useful
to
give
them
an
unambiguous
identifier.
That
is,
it
is
useful
for
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
s
to
expand
to
IRIs
so
that
developers
don't
accidentally
step
on
each
other's
Web
Vocabulary
terms.
For
example,
the
term
<code>
name
</code>
may
map
directly
to
the
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
<code>
http://xmlns.com/foaf/0.1/name
</code>.
This
allows
JSON-LD
documents
to
be
constructed
using
the
common
JSON
practice
of
simple
name/value
pairs
while
ensuring
that
the
data
is
useful
outside
of
the
page,
API
or
database
in
which
it
resides.
<ins class="diff-new">The
value
of
a
term
mapping
</ins><em class="rfc2119" title="must"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
be
a
simple
string
with
the
lexical
form
of
an
absolute
</ins><a class="tref internalDFN" title="iri" href="#dfn-iri"><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr></a>.
</p>
<p>
These
Linked
Data
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
s
are
typically
collected
in
a
context
document
that
would
look
something
like
this:
</p>
<del class="diff-old">{
  &quot;@context&quot;: {
    &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
    &quot;homepage&quot;: &quot;http://xmlns.com/foaf/0.1/homepage&quot;,
    &quot;avatar&quot;: &quot;http://xmlns.com/foaf/0.1/avatar&quot;
  }
</del>
<pre class="example">{
<ins class="diff-chg">  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": "http://xmlns.com/foaf/0.1/homepage",
    "avatar": "http://xmlns.com/foaf/0.1/avatar"
  }
</ins>
}
</pre>
<p>
This
context
document
can
then
be
used
in
an
JSON-LD
document
by
adding
a
single
line.
The
JSON
markup
as
shown
in
the
previous
section
could
be
changed
as
follows
to
link
to
the
context
document:
</p>
<del class="diff-old">{
  
  &quot;name&quot;: &quot;Manu Sporny&quot;,
  &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
</del>
<pre class="example">{
  <span class="diff">"@context": "http://example.org/json-ld-contexts/person",</span>
<ins class="diff-chg">  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "avatar": "http://twitter.com/account/profile_image/manusporny"
</ins>
}
</pre>
<p>
The
additions
above
transform
the
previous
JSON
document
into
a
JSON
document
with
added
semantics
because
the
<code>
@context
</code>
specifies
how
the
<strong>
name
</strong>,
<strong>
homepage
</strong>,
and
<strong>
avatar
</strong>
terms
map
to
IRIs.
Mapping
those
keys
to
IRIs
gives
the
data
global
context.
If
two
developers
use
the
same
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
to
describe
a
property,
they
are
more
than
likely
expressing
the
same
concept.
This
allows
both
developers
to
re-use
each
others
data
without
having
to
agree
to
how
their
data
will
inter-operate
on
a
site-by-site
basis.
Contexts
may
also
contain
datatype
information
for
certain
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
s
as
well
as
other
processing
instructions
for
the
JSON-LD
processor.
</p>
<p>
Contexts
may
be
specified
in-line.
This
ensures
that
JSON-LD
documents
can
be
processed
when
a
JSON-LD
processor
does
not
have
access
to
the
Web.
</p>
<del class="diff-old">{
  &quot;@context&quot;: {
    &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
    &quot;homepage&quot;: &quot;http://xmlns.com/foaf/0.1/homepage&quot;,
    &quot;avatar&quot;: &quot;http://xmlns.com/foaf/0.1/avatar&quot;
  },
  &quot;name&quot;: &quot;Manu Sporny&quot;,
  &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
</del>
<pre class="example">{
  <span class="diff">"@context": {
<ins class="diff-chg">    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": "http://xmlns.com/foaf/0.1/homepage",
    "avatar": "http://xmlns.com/foaf/0.1/avatar"
  },</span>
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "avatar": "http://twitter.com/account/profile_image/manusporny"
</ins>
}
</pre>
<p>
Contexts
may
be
used
at
any
time
a
<a class="tref internalDFN" title="json_object" href="#dfn-json_object">
JSON
object
</a>
is
defined,
and
a
<a class="tref internalDFN" title="json_object" href="#dfn-json_object">
JSON
object
</a>
may
specify
multiple
contexts,
to
be
processed
in
order,
for
example
to
include
standard
prefix
definitions
along
with
<del class="diff-old">a
local
language
definition
used
to
set
the
language
of
plain
literal
s:
</del>
<ins class="diff-chg">an
author-specific
prefix
definition.
</ins>
</p>
<p>
The
set
of
contexts
defined
within
a
specific
<a class="tref internalDFN" title="json_object" href="#dfn-json_object">
JSON
Object
</a>
is
termed
a
<dfn title="local_context" id="dfn-local_context">
local
context
</dfn>.
The
<dfn title="active_context" id="dfn-active_context">
active
context
</dfn>
refers
to
the
accumulation
of
<a class="tref internalDFN" title="local_context" href="#dfn-local_context">
local
context
</a>
s
that
are
in
scope
at
a
specific
point
within
the
document.
<ins class="diff-new">The
following
example
specifies
an
external
context
and
then
layers
a
local
context
on
top
of
the
external
context:
</ins>
</p>
<del class="diff-old">{
  &quot;@context&quot;: [
    &quot;http://example.org/json-ld-contexts/person&quot;,
    {
      &quot;@language&quot;: &quot;en&quot;
    }
  ],
  &quot;name&quot;: &quot;Manu Sporny&quot;,
  &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
</del>
<pre class="example">{
  <span class="diff">"@context": [
<ins class="diff-chg">    "http://example.org/json-ld-contexts/person",
    {
      "pic": "http://xmlns.com/foaf/0.1/avatar"
    }
  ],</span>
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
</ins>  <span class="diff">"pic": "http://twitter.com/account/profile_image/manusporny"</span>
}
</pre>
<p>
JSON-LD
strives
to
ensure
that
developers
don't
have
to
change
the
JSON
that
is
going
into
and
being
returned
from
their
Web
APIs.
This
means
that
developers
can
also
specify
a
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
for
JSON
data
in
an
out-of-band
fashion.
This
is
described
later
in
this
document.
</p>
<p>
JSON-LD
uses
a
special
type
of
machine-readable
document
called
a
<dfn title="web_vocabulary" id="dfn-web_vocabulary">
Web
Vocabulary
</dfn>
to
define
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
s
that
are
then
used
to
describe
concepts
and
<del class="diff-old">&quot;things&quot;
</del>
<ins class="diff-chg">"things"
</ins>
in
the
world.
Typically,
these
Web
Vocabulary
documents
have
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>
es
associated
with
them
and
contain
a
number
of
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
declarations.
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
Prefix
</a>
es
are
helpful
when
a
developer
wants
to
mix
multiple
vocabularies
together
in
a
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>,
but
does
not
want
to
go
to
the
trouble
of
defining
every
single
term
in
every
single
vocabulary.
Some
Web
Vocabularies
may
have
dozens
of
terms
defined.
If
a
developer
wants
to
use
3-4
different
vocabularies,
the
number
of
terms
that
would
have
to
be
declared
in
a
single
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
could
become
quite
large.
To
reduce
the
number
of
different
terms
that
must
be
defined,
JSON-LD
also
allows
prefixes
to
be
used
to
compact
IRIs.
</p>
<p>
For
example,
the
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
<code>
http://xmlns.com/foaf/0.1/
</code>
specifies
a
<a class="tref internalDFN" title="web_vocabulary" href="#dfn-web_vocabulary">
Web
Vocabulary
</a>
which
may
be
represented
using
the
<code>
foaf
</code>
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>.
The
<code>
foaf
</code>
Web
Vocabulary
contains
a
term
called
<strong>
name
</strong>.
If
you
join
the
<code>
foaf
</code>
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>
with
the
<strong>
name
</strong>
suffix,
you
can
build
a
compact
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
that
will
expand
out
into
an
absolute
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
for
the
<code>
http://xmlns.com/foaf/0.1/name
</code>
vocabulary
term.
That
is,
the
compact
<del class="diff-old">IRI,
</del>
<abbr title="Internationalized Resource Identifier">
<ins class="diff-chg">IRI
</ins></abbr>,
or
short-form,
is
<code>
foaf:name
</code>
and
the
expanded-form
is
<code>
http://xmlns.com/foaf/0.1/name
</code>.
This
vocabulary
term
is
used
to
specify
a
person's
name.
</p>
<p>
Developers,
and
machines,
are
able
to
use
this
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
(plugging
it
directly
into
a
web
browser,
for
instance)
to
go
to
the
term
and
get
a
definition
of
what
the
term
means.
Much
like
we
can
use
<a href="http://wordnet.princeton.edu/">
WordNet
</a>
today
to
see
the
definition
of
words
in
the
English
language.
Developers
and
machines
need
the
same
sort
of
definition
of
terms.
IRIs
provide
a
way
to
ensure
that
these
terms
are
unambiguous.
</p>
<p>
The
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
provides
a
collection
of
vocabulary
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
s
and
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>
es
that
can
be
used
to
expand
JSON
keys
and
values
into
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s.
</p>
<p class="note">
To
ensure
the
best
possible
performance,
it
is
a
best
practice
to
put
the
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
definition
at
the
top
of
the
JSON-LD
document.
If
it
isn't
listed
first,
processors
have
to
save
each
key-value
pair
until
the
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
is
processed.
This
creates
a
memory
and
complexity
burden
for
one-pass
processors.
</p>
<del class="diff-old">2.4.1
External
Contexts
Authors
may
choose
to
declare
JSON-LD
context
s
in
external
documents
to
promote
re-use
of
contexts
as
well
as
reduce
the
size
of
JSON-LD
documents.
In
order
to
use
an
external
context,
an
author
may
specify
an
IRI
to
a
valid
JSON-LD
document.
The
referenced
document
must
have
a
top-level
JSON
Object
.
The
value
of
any
@context
key
within
that
object
is
substituted
for
the
IRI
within
the
referencing
document
to
have
the
same
effect
as
if
the
value
were
specified
inline
within
the
referencing
document.
The
following
example
demonstrates
the
use
of
an
external
context:
{
  ,
  &quot;name&quot;: &quot;Manu Sporny&quot;,
  &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
Authors
may
also
import
multiple
contexts
or
a
combination
of
external
and
local
contexts
by
specifying
a
list
of
contexts:
{
  
  &quot;name&quot;: &quot;Manu Sporny&quot;,
  &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
  &quot;celebrates&quot;:
  {
     &quot;@type&quot;: &quot;Event&quot;,
     &quot;description&quot;: &quot;International Talk Like a Pirate Day&quot;,
     &quot;date&quot;: &quot;R/2011-09-19&quot;
  }
}
Each
context
in
a
list
will
be
evaluated
in-order.
Duplicate
mappings
within
the
context
s
must
be
overwritten
on
a
last-defined-overrides
basis.
The
context
list
must
contain
either
de-referenceable
IRI
s
or
JSON
Object
s
that
conform
to
the
context
syntax
as
described
in
this
document.
External
JSON-LD
context
documents
may
contain
extra
information
located
outside
of
the
@context
key,
such
as
documentation
about
the
prefix
es
declared
in
the
document.
It
is
also
recommended
that
a
human-readable
document
encoded
in
HTML+RDFa
[
HTML-RDFA
]
or
other
Linked
Data
compatible
format
is
served
as
well
to
explain
the
correct
usage
of
the
JSON-LD
context
document.
</del>
</div>
<div id="from-json-to-json-ld" class="section">
<h3>
<span class="secno">
<del class="diff-old">2.5
</del>
<ins class="diff-chg">2.4
</ins>
</span>
From
JSON
to
JSON-LD
</h3>
<p>
If
a
set
of
<del class="diff-old">terms
</del>
<a class="tref internalDFN" title="term" href="#dfn-term">
<ins class="diff-chg">term
</ins></a><ins class="diff-chg">
s
</ins>
such
as,
<strong>
name
</strong>,
<strong>
homepage
</strong>,
and
<strong>
avatar
</strong>,
are
defined
in
a
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>,
and
that
context
is
used
to
resolve
the
names
in
JSON
objects,
machines
are
able
to
automatically
expand
the
terms
to
something
meaningful
and
unambiguous,
like
this:
</p>
<del class="diff-old">{
  &quot;&quot;: &quot;Manu Sporny&quot;,
  &quot;&quot;: &quot;http://manu.sporny.org&quot;
  &quot;&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
</del>
<pre class="example">{
<ins class="diff-chg">  "<span class="diff">http://xmlns.com/foaf/0.1/name</span>": "Manu Sporny",
  "<span class="diff">http://xmlns.com/foaf/0.1/homepage</span>": "http://manu.sporny.org"
  "<span class="diff">http://rdfs.org/sioc/ns#avatar</span>": "http://twitter.com/account/profile_image/manusporny"
</ins>
}
</pre>
<p>
Doing
this
allows
JSON
to
be
unambiguously
machine-readable
without
requiring
developers
to
drastically
change
their
workflow.
</p>
<p class="note">
Please
note
that
this
JSON-LD
document
doesn't
define
the
subject
and
will
thus
result
in
an
unlabeled
or
blank
node.
</p>
</div>
</div>
<div id="basic-concepts" class="section">
<h2>
<span class="secno">
3.
</span>
Basic
Concepts
</h2>
<p>
JSON-LD
is
designed
to
ensure
that
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
concepts
can
be
marked
up
in
a
way
that
is
simple
to
understand
and
author
by
Web
developers.
In
many
cases,
regular
JSON
markup
can
become
Linked
Data
with
the
simple
addition
of
a
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>.
As
more
JSON-LD
features
are
used,
more
semantics
are
added
to
the
JSON
markup.
</p>
<div id="iris" class="section">
<h3>
<span class="secno">
3.1
</span>
IRIs
</h3>
<p>
Expressing
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s
are
fundamental
to
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
as
that
is
how
most
<a class="tref internalDFN" title="subject" href="#dfn-subject">
subject
</a>
s
and
many
<a class="tref internalDFN" title="object" href="#dfn-object">
object
</a>
are
named.
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s
can
be
expressed
in
a
variety
of
different
ways
in
JSON-LD.
</p>
<ol>
<li>
<del class="diff-old">In
general,
</del>
<ins class="diff-chg">Except
within
a
</ins><a class="tref internalDFN" title="context" href="#dfn-context"><ins class="diff-chg">
context
</ins></a><ins class="diff-chg">
definition,
</ins>
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
s
in
the
key
position
in
a
<a class="tref internalDFN" title="json_object" href="#dfn-json_object">
JSON
object
</a>
that
have
a
mapping
to
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
or
another
<del class="diff-old">key
</del>
<a class="tref internalDFN" title="term" href="#dfn-term">
<ins class="diff-chg">term
</ins></a>
in
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
<ins class="diff-chg">active
</ins>
context
</a>
are
expanded
to
an
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
by
JSON-LD
processors.
<del class="diff-old">There
are
special
rules
for
processing
keys
in
@context
and
when
dealing
with
keys
that
start
with
the
@subject
character.
</del>
</li>
<li>
An
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
is
generated
for
the
<del class="diff-old">value
specified
using
@subject
,
if
it
is
a
</del>
<a class="tref internalDFN" title="string" href="#dfn-string">
string
<del class="diff-old">.
An
IRI
</del>
</a>
<del class="diff-old">is
generated
for
the
</del>
value
specified
using
<code>
<ins class="diff-new">@id
</ins></code><ins class="diff-new">
or
</ins><code>
@type
</code>.
</li>
<li>
An
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
is
generated
for
the
<del class="diff-old">value
specified
using
the
@iri
keyword.
An
IRI
</del>
<a class="tref internalDFN" title="string" href="#dfn-string">
<ins class="diff-chg">string
</ins>
</a>
<del class="diff-old">is
generated
when
</del>
<ins class="diff-chg">value
of
any
key
for
which
</ins>
there
are
<del class="diff-old">@coerce
</del>
<a class="tref internalDFN" title="coercion" href="#dfn-coercion">
<ins class="diff-chg">coercion
</ins></a>
rules
in
effect
<del class="diff-old">for
a
key
named
</del>
<ins class="diff-chg">that
identify
the
value
as
an
</ins>
<code>
<del class="diff-old">@iri
</del>
<ins class="diff-chg">@id
</ins>
</code>.
</li>
</ol>
<p>
IRIs
<ins class="diff-new">may
be
represented
as
an
absolute
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr>,<ins class="diff-new">
a
</ins><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-new">
term
</ins></a>,<ins class="diff-new">
or
a
</ins><a class="tref internalDFN" title="prefix" href="#dfn-prefix"><ins class="diff-new">
prefix
</ins></a>:suffix<ins class="diff-new">
construct.
</ins></p><p><ins class="diff-new">
IRIs
</ins>
can
be
expressed
directly
in
the
key
position
like
so:
</p>
<del class="diff-old">{
...
  &quot;&quot;: &quot;Manu Sporny&quot;,
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "<span class="diff">http://xmlns.com/foaf/0.1/name</span>": "Manu Sporny",
...
</ins>
}
</pre>
<p>
In
the
example
above,
the
key
<code>
http://xmlns.com/foaf/0.1/name
</code>
is
interpreted
as
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>,
as
opposed
to
being
interpreted
as
a
string.
</p>
<p>
Term
expansion
occurs
for
IRIs
if
<ins class="diff-new">the
value
matches
</ins>
a
<a class="tref internalDFN" title="term" href="#dfn-term">
term
<del class="diff-old">is
</del>
</a>
defined
within
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>:
</p>
<del class="diff-old">{
  &quot;&quot;},
...
  &quot;&quot;: &quot;Manu Sporny&quot;,
...
</del>
<pre class="example">{
<ins class="diff-chg">  "<span class="diff">@context</span>": { "<span class="diff">name</span>": "<span class="diff">http://xmlns.com/foaf/0.1/name</span>" },
...
  "<span class="diff">name</span>": "Manu Sporny",
...
</ins>
}
</pre>
<p>
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
Prefix
</a>
es
are
expanded
when
<del class="diff-old">used
in
keys:
</del>
<ins class="diff-chg">the
form
of
the
value
is
</ins><code><ins class="diff-chg">
prefix:suffix
</ins></code>,<ins class="diff-chg">
and
the
prefix
matches
a
</ins><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-chg">
term
</ins></a><ins class="diff-chg">
defined
within
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-chg">
active
context
</ins></a>:
</p>
<del class="diff-old">{
  &quot;&quot;},
...
  &quot;&quot;: &quot;Manu Sporny&quot;,
...
</del>
<pre class="example">{
<ins class="diff-chg">  "<span class="diff">@context</span>": { "<span class="diff">foaf</span>": "<span class="diff">http://xmlns.com/foaf/0.1/</span>" },
...
  "<span class="diff">foaf:name</span>": "Manu Sporny",
...
</ins>
}
</pre>
<p>
<a class="tref internalDFN" title="term" href="#dfn-term">
<ins class="diff-new">Term
</ins></a><ins class="diff-new">
s
are
case
sensitive,
and
</ins><em class="rfc2119" title="must"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
be
matched
using
a
case-sensitive
comparison.
</ins></p><p>
<code>
foaf:name
</code>
above
will
automatically
expand
out
to
the
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
<code>
http://xmlns.com/foaf/0.1/name
</code>.
<ins class="diff-new">See
</ins><a href="#prefixes"><ins class="diff-new">
Prefixes
</ins></a><ins class="diff-new">
for
more
details.
</ins>
</p>
<p>
An
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
is
generated
when
a
value
is
associated
with
a
key
using
the
<code>
<del class="diff-old">@iri
</del>
<ins class="diff-chg">@id
</ins>
</code>
keyword:
</p>
<del class="diff-old">{
...
  &quot;homepage&quot;: { &quot;&quot;: &quot;http://manu.sporny.org&quot; }
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "homepage": { "<span class="diff">@id</span>": "http://manu.sporny.org" }
...
</ins>
}
</pre>
<p class="note">
<ins class="diff-new">Specifying
a
</ins><a class="tref internalDFN" title="json_object" href="#dfn-json_object"><ins class="diff-new">
JSON
Object
</ins></a><ins class="diff-new">
with
an
</ins><code><ins class="diff-new">
@id
</ins></code><ins class="diff-new">
key
is
used
to
represent
an
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr>,<ins class="diff-new">
but
it
also
is
the
mechanism
by
which
a
</ins><a class="tref internalDFN" title="subject" href="#dfn-subject"><ins class="diff-new">
subject
</ins></a><ins class="diff-new">
is
defined.
This
is
an
example
of
</ins><a class="tref internalDFN" title="chaining" href="#dfn-chaining"><ins class="diff-new">
chaining
</ins></a><ins class="diff-new">
in
JSON-LD,
an
issue
covered
further
in
</ins><a href="#chaining"><ins class="diff-new">
Chaining
</ins></a>.</p>
<p>
If
type
<a class="tref internalDFN" title="coercion" href="#dfn-coercion">
coercion
</a>
rules
are
specified
in
the
<code>
@context
</code>
for
a
particular
<del class="diff-old">vocabulary
term,
</del>
<a class="tref internalDFN" title="term" href="#dfn-term">
<ins class="diff-chg">term
</ins></a><ins class="diff-chg">
or
property
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-chg">
IRI
</ins></abbr>,
an
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
is
generated:
</p>
<del class="diff-old">  &quot;@context&quot;:
  {
    ...
    &quot;@coerce&quot;:
    {
      &quot;@iri&quot;: &quot;homepage&quot;
    }
  }
...
  &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
...
</del>
<pre class="example">{<span class="diff">
<ins class="diff-chg">  "@context": {
    ...
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id"
    }
    ...
  }</span>
...
  "homepage": "http://manu.sporny.org/",
...
</ins>
}
</pre>
<p>
Even
though
the
value
<code>
http://manu.sporny.org/
</code>
is
a
<a class="tref internalDFN" title="string" href="#dfn-string">
string
</a>,
the
type
<a class="tref internalDFN" title="coercion" href="#dfn-coercion">
coercion
</a>
rules
will
transform
the
value
into
an
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
when
processed
by
a
JSON-LD
Processor
</p>
<del class="diff-old">IRIs
may
be
represented
as
an
absolute
IRI,
a
term
,
a
prefix
:
term
construct,
or
as
a
value
relative
to
@base
or
@vocab
.
</del>
</div>
<div id="identifying-the-subject" class="section">
<h3>
<span class="secno">
3.2
</span>
Identifying
the
Subject
</h3>
<p>
To
be
able
to
externally
reference
nodes,
it
is
important
that
each
node
has
an
unambiguous
identifier.
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s
are
a
fundamental
concept
of
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>,
and
nodes
should
have
a
de-referencable
identifier
used
to
name
and
locate
them.
For
nodes
to
be
truely
linked,
de-referencing
the
identifier
should
result
in
a
representation
of
that
node.
Associating
an
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
with
a
node
tells
an
application
that
the
returned
document
contains
a
description
of
the
node
requested.
</p>
<p>
JSON-LD
documents
may
also
contain
descriptions
of
other
nodes,
so
it
is
necessary
to
be
able
to
uniquely
identify
each
node
which
may
be
externally
referenced.
</p>
<p>
A
<a class="tref internalDFN" title="subject" href="#dfn-subject">
subject
</a>
of
an
object
in
JSON
is
declared
using
the
<code>
<del class="diff-old">@subject
</del>
<ins class="diff-chg">@id
</ins>
</code>
key.
The
subject
is
the
first
piece
of
information
needed
by
the
JSON-LD
processor
in
order
to
create
the
(subject,
property,
object)
tuple,
also
known
as
a
triple.
</p>
<del class="diff-old">{
...
  &quot;&quot;,
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "<span class="diff">@id</span>": "<span class="diff">http://example.org/people#joebob</span>",
...
</ins>
}
</pre>
<p>
The
example
above
would
set
the
subject
to
the
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
<code>
http://example.org/people#joebob
</code>.
</p>
<p class="note">
To
ensure
the
best
possible
performance,
it
is
a
best
practice
to
put
the
<code>
<del class="diff-old">@subject
</del>
<ins class="diff-chg">@id
</ins>
</code>
key
before
other
key-value
pairs
in
an
object.
If
it
isn't
listed
first,
processors
have
to
save
each
key-value
pair
until
<code>
<del class="diff-old">@subject
</del>
<ins class="diff-chg">@id
</ins>
</code>
is
processed
before
they
can
create
valid
triples.
This
creates
a
memory
and
complexity
burden
for
one-pass
processors.
</p>
</div>
<div id="specifying-the-type" class="section">
<h3>
<span class="secno">
3.3
</span>
Specifying
the
Type
</h3>
<p>
The
type
of
a
particular
subject
can
be
specified
using
the
<code>
@type
</code>
key.
Specifying
the
type
in
this
way
will
generate
a
triple
of
the
form
(subject,
type,
type-iri).
</p>
<p>
To
be
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>,
types
<em class="rfc2119" title="must">
must
</em>
be
uniquely
identified
by
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>.
</p>
<del class="diff-old">{
...
  &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
  &quot;&quot;,
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "@id": "http://example.org/people#joebob",
  "<span class="diff">@type</span>": "<span class="diff">http://xmlns.com/foaf/0.1/Person</span>",
...
</ins>
}
</pre>
<del class="diff-old">The
example
above
would
generate
the
following
triple
if
the
JSON-LD
document
is
mapped
to
RDF
(in
N-Triples
notation):
&lt;http://example.org/people#joebob&gt;
   &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt;
&lt;http://xmlns.com/foaf/0.1/Person&gt;
.
</del>
</div>
<div id="strings" class="section">
<h3>
<span class="secno">
3.4
</span>
Strings
</h3>
<p>
Regular
text
strings,
also
referred
to
as
<dfn title="plain_literal" id="dfn-plain_literal">
plain
literal
</dfn>
s,
are
easily
expressed
using
regular
JSON
<a class="tref internalDFN" title="string" href="#dfn-string">
string
</a>
s.
</p>
<del class="diff-old">{
...
  &quot;name&quot;: &quot;&quot;,
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "name": "<span class="diff">Mark Birbeck</span>",
...
</ins>
}
</pre>
</div>
<div id="string-internationalization" class="section">
<h3>
<span class="secno">
3.5
</span>
String
Internationalization
</h3>
<p>
JSON-LD
makes
an
assumption
that
strings
with
associated
language
encoding
information
are
not
very
common
when
used
in
JavaScript
and
Web
Services.
Thus,
it
takes
a
little
more
effort
to
express
strings
with
associated
language
information.
</p>
<del class="diff-old">{
...
  &quot;name&quot;: 
  {
    &quot;@literal&quot;: &quot;花澄&quot;,
    &quot;@language&quot;: &quot;ja&quot;
  }
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "name": <span class="diff">
  {
    "@value": "&#33457;&#28548;",
    "@language": "ja"
  }</span>
...
</ins>
}
</pre>
<p>
The
example
above
would
generate
a
<a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal">
plain
literal
</a>
for
<em>
<del class="diff-old">花澄
</del>
<ins class="diff-chg">&#33457;&#28548;
</ins>
</em>
and
associate
the
<code>
ja
</code>
language
code
with
the
triple
that
is
generated.
Languages
<em class="rfc2119" title="must">
must
</em>
be
expressed
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-BCP47">
BCP47
</a>
</cite>
]
format.
</p>
<del class="diff-old">It
is
also
possible
to
set
a
language
to
use
within
a
@context
,
to
allow
specify
a
language
to
apply
to
all
plain
literal
s
within
the
scope
of
the
context
{
  &quot;@context:&quot; {
    &quot;@language&quot;: &quot;ja&quot;
  },
...
  &quot;name&quot;: 
...
}
</del>
</div>
<div id="typed-literals" class="section">
<h3>
<span class="secno">
3.6
</span>
Typed
Literals
</h3>
<p>
A
value
with
an
associated
datatype,
also
known
as
a
<dfn title="typed_literal" id="dfn-typed_literal">
typed
literal
</dfn>,
is
indicated
by
associating
a
literal
with
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
which
indicates
the
literal's
datatype.
Typed
literals
may
be
expressed
in
JSON-LD
in
three
ways:
</p>
<ol>
<li>
By
utilizing
the
<code>
<del class="diff-old">@coerce
</del>
<ins class="diff-chg">@type
</ins>
</code>
<del class="diff-old">keyword.
</del>
<ins class="diff-chg">keyword
when
defining
a
</ins><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-chg">
term
</ins></a><ins class="diff-chg">
within
a
</ins><code><ins class="diff-chg">
@context
</ins></code><ins class="diff-chg">
section.
</ins>
</li>
<li>
By
utilizing
the
expanded
form
for
specifying
objects.
</li>
<li>
By
using
a
native
JSON
datatype.
</li>
</ol>
<p>
The
first
example
uses
the
<code>
<del class="diff-old">@coerce
</del>
<ins class="diff-chg">@type
</ins>
</code>
keyword
to
express
a
typed
literal:
</p>
<del class="diff-old">  &quot;@context&quot;:
  {
    &quot;modified&quot;:  &quot;http://purl.org/dc/terms/modified&quot;,
    &quot;dateTime&quot;: &quot;http://www.w3.org/2001/XMLSchema#dateTime&quot;
    &quot;@coerce&quot;:
    {
      &quot;dateTime&quot;: &quot;modified&quot;
    }
  }
...
  &quot;modified&quot;: &quot;2010-05-29T14:17:39+02:00&quot;,
...
</del>
<pre class="example">{
  <span class="diff">"@context": {
<ins class="diff-chg">    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "modified": {
      "@id": "http://purl.org/dc/terms/modified",
      "@type": "xsd:dateTime"
    }
  }</span>
...
  "modified": "2010-05-29T14:17:39+02:00",
...
</ins>
}
</pre>
<p>
The
second
example
uses
the
expanded
form
for
specifying
objects:
</p>
<del class="diff-old">{
...
  &quot;modified&quot;: 
  {
    &quot;@literal&quot;: &quot;2010-05-29T14:17:39+02:00&quot;,
    &quot;@datatype&quot;: &quot;dateTime&quot;
  }
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "modified": <span class="diff">{
    "@value": "2010-05-29T14:17:39+02:00",
    "@type": "xsd:dateTime"
  }</span>
...
</ins>
}
</pre>
<p>
Both
examples
above
would
generate
an
object
with
the
literal
value
of
<code>
2010-05-29T14:17:39+02:00
</code>
and
the
datatype
of
<code>
http://www.w3.org/2001/XMLSchema#dateTime
</code>.
</p>
<p>
The
third
example
uses
a
built-in
native
JSON
type,
a
<a class="tref internalDFN" title="number" href="#dfn-number">
number
</a>,
to
express
a
datatype:
</p>
<del class="diff-old">{
...
  &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
  &quot;age&quot;: 
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "@id": "http://example.org/people#joebob",
  "age": <span class="diff">31</span>
...
</ins>
}
</pre>
<p>
The
example
above
<del class="diff-old">would
generate
</del>
<ins class="diff-chg">is
really
just
a
shorthand
for
</ins>
the
<del class="diff-old">following
triple:
</del>
<ins class="diff-chg">following:
</ins>
</p>
<del class="diff-old">&lt;http://example.org/people#joebob&gt;
   &lt;http://xmlns.com/foaf/0.1/age&gt;
&quot;31&quot;^^&lt;http://www.w3.org/2001/XMLSchema#integer&gt;
.
</del>
<pre class="example">{
<ins class="diff-chg">...
  "@id": "http://example.org/people#joebob",
  "age": <span class="diff">{
    "@value": "31",
    "@type": "http://www.w3.org/2001/XMLSchema#integer"
  }</span>
...
}
</ins>
</pre>
<p class="note">
<ins class="diff-new">The
</ins><code><ins class="diff-new">
@type
</ins></code><ins class="diff-new">
keyword
is
also
used
to
associate
a
type
with
an
object.
Although
the
same
keyword
is
used
in
both
places,
the
concept
of
object
type
and
literal
datatype
are,
in
fact,
different.
This
is
similar
to
object-oriented
programming
languages
where
both
scalar
and
structured
types
use
the
same
class
inheritance
mechanism,
even
though
scalar
types
and
structured
types
are
inherently
different.
</ins></p>
</div>
<div id="multiple-objects-for-a-single-property" class="section">
<h3>
<span class="secno">
3.7
</span>
Multiple
Objects
for
a
Single
Property
</h3>
<p>
A
JSON-LD
author
can
express
multiple
triples
in
a
compact
way
by
using
<a class="tref internalDFN" title="array" href="#dfn-array">
array
</a>
s.
If
a
subject
has
multiple
values
for
the
same
property,
the
author
<em class="rfc2119" title="may">
may
</em>
express
each
property
as
an
<a class="tref internalDFN" title="array" href="#dfn-array">
array
</a>.
</p>
<p class="note">
In
JSON-LD,
multiple
objects
on
a
property
are
not
ordered.
This
is
because
typically
graphs
are
not
inherently
ordered
data
structures.
To
see
more
on
creating
ordered
collections
in
JSON-LD,
see
<a href="#rdf-collection">
Lists
</a>.
</p>
<del class="diff-old">{
...
  &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
  &quot;nick&quot;: ,
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "@id": "http://example.org/people#joebob",
  "nick": <span class="diff">[ "joe", "bob", "jaybee" ]</span>,
...
</ins>
}
</pre>
<p>
The
markup
shown
above
would
generate
the
following
triples:
</p>
<del class="diff-old">&lt;http://example.org/people#joebob&gt;
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
      &quot;joe&quot; .
&lt;http://example.org/people#joebob&gt;
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
      &quot;bob&quot; .
&lt;http://example.org/people#joebob&gt;
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
&quot;jaybee&quot;
</del>
<pre class="example">&lt;http://example.org/people#joebob&gt;
<ins class="diff-chg">   &lt;http://xmlns.com/foaf/0.1/nick&gt;
      "joe" .
&lt;http://example.org/people#joebob&gt;
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
      "bob" .
&lt;http://example.org/people#joebob&gt;
   &lt;http://xmlns.com/foaf/0.1/nick&gt;
"jaybee"
</ins>
.
</pre>
</div>
<div id="multiple-literals-for-a-single-property" class="section">
<h3>
<span class="secno">
3.8
</span>
Multiple
<del class="diff-old">Typed
</del>
Literals
for
a
Single
Property
</h3>
<p>
Multiple
<del class="diff-old">typed
</del>
<a class="tref internalDFN" title="literal" href="#dfn-literal">
literal
</a>
s
may
also
be
expressed
using
the
expanded
form
for
objects:
</p>
<del class="diff-old">{
...
  &quot;@subject&quot;: &quot;http://example.org/articles/8&quot;,
  &quot;modified&quot;: 
  [
    {
      &quot;@literal&quot;: &quot;2010-05-29T14:17:39+02:00&quot;,
      &quot;@datatype&quot;: &quot;dateTime&quot;
    },
    {
      &quot;@literal&quot;: &quot;2010-05-30T09:21:28-04:00&quot;,
      &quot;@datatype&quot;: &quot;dateTime&quot;
    }
  ]
...
</del>
<pre class="example">{
<ins class="diff-chg">  "@id": "http://example.org/articles/8",
  "dc:title": <span class="diff">
  [
    {"@value": "Das Kapital", "@language": "de"},
    {"@value": "Capital", "@language": "en"}
  ]</span>
</ins>
}
</pre>
<p>
The
markup
shown
above
would
generate
the
following
triples:
</p>
<del class="diff-old">&lt;http://example.org/articles/8&gt;
   &lt;http://purl.org/dc/terms/modified&gt;
      &quot;2010-05-29T14:17:39+02:00&quot;^^http://www.w3.org/2001/XMLSchema#dateTime .
&lt;http://example.org/articles/8&gt;
   &lt;http://purl.org/dc/terms/modified&gt;
&quot;2010-05-30T09:21:28-04:00&quot;^^http://www.w3.org/2001/XMLSchema#dateTime
</del>
<pre class="example">&lt;http://example.org/articles/8&gt;
<ins class="diff-chg">   &lt;http://purl.org/dc/terms/title&gt;
      "Das Kapital"@de .
&lt;http://example.org/articles/8&gt;
   &lt;http://purl.org/dc/terms/title&gt;
"Capital"@en
</ins>
.
</pre>
</div>
<div id="rdf-collection" class="section">
<h3>
<span class="secno">
3.9
</span>
Lists
</h3>
<p>
Because
graphs
do
not
describe
ordering
for
links
between
nodes,
in
contrast
to
plain
JSON,
multi-valued
properties
in
JSON-LD
do
not
provide
an
ordering
of
the
listed
objects.
For
example,
consider
the
following
simple
document:
</p>
<del class="diff-old">  {
...
  &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
  &quot;nick&quot;: ,
...
</del>
  <pre class="example">{
<ins class="diff-chg">...
  "@id": "http://example.org/people#joebob",
  "nick": <span class="diff">[ "joe", "bob", "jaybee" ]</span>,
...
</ins>
}
</pre>
<p>
This
results
in
three
triples
being
generated,
each
relating
the
subject
to
an
individual
object,
with
no
inherent
order.
</p>
<p>
<del class="diff-old">To
preserve
the
order
of
the
objects,
RDF-based
languages,
such
as
[
TURTLE
]
use
the
concept
of
an
rdf:List
(as
described
in
[
RDF-SCHEMA
]).
This
uses
a
sequence
of
unlabeled
nodes
with
properties
describing
a
value,
a
null-terminated
next
property.
Without
specific
syntactical
support,
this
could
be
represented
in
JSON-LD
as
follows:
  {
...
  &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
  &quot;nick&quot;: ,
    ,
    
      ,
      
        ,
        
        
      
    
  ,
...
}
</del>
As
<del class="diff-old">this
notation
is
rather
unwieldy
and
</del>
the
notion
of
ordered
collections
is
rather
important
in
data
modeling,
it
is
useful
to
have
specific
language
support.
In
JSON-LD,
a
list
may
be
represented
using
the
<code>
@list
</code>
keyword
as
follows:
</p>
<del class="diff-old">  {
...
  &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
  &quot;foaf:nick&quot;: ,
...
</del>
  <pre class="example">{
<ins class="diff-chg">...
  "@id": "http://example.org/people#joebob",
  "foaf:nick": <span class="diff">{ "@list": [ "joe", "bob", "jaybee" ] }</span>,
...
</ins>
}
</pre>
<p>
This
describes
the
use
of
this
<a class="tref internalDFN" title="array" href="#dfn-array">
array
</a>
as
being
ordered,
and
order
is
maintained
through
<del class="diff-old">normalization
and
RDF
conversion
</del>
<ins class="diff-chg">alternate
representations
</ins>
as
described
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-JSON-LD-API">
JSON-LD-API
</a>
</cite>
].
If
every
use
of
a
given
multi-valued
property
is
a
list,
this
may
be
abbreviated
by
adding
an
<code>
<del class="diff-old">@coerce
</del>
<ins class="diff-chg">@type
</ins>
</code>
<del class="diff-old">term:
</del>
<a class="tref internalDFN" title="coercion" href="#dfn-coercion">
<ins class="diff-chg">coercion
</ins></a>:
</p>
<del class="diff-old">  {
  
    ...
    
      
    
  ,
...
  &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
  &quot;foaf:nick&quot;: ,
...
</del>
  <pre class="example">{
  <span class="diff">"@context": {
<ins class="diff-chg">    ...
    "nick": {
      "@id": "http://xmlns.com/foaf/0.1/nick",
      "@list": true
    }
}</span>,
...
  "@id": "http://example.org/people#joebob",
  "nick": <span class="diff">[ "joe", "bob", "jaybee" ]</span>,
...
</ins>
}
</pre>
<p>
<del class="diff-old">The
@list
keyword
can
be
used
</del>
<ins class="diff-chg">List
coercion
is
specified
</ins>
within
<ins class="diff-new">an
expanded
</ins><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-new">
term
</ins></a><ins class="diff-new">
definition
using
</ins>
the
<code>
<del class="diff-old">@coerce
</del>
<ins class="diff-chg">@list
</ins>
</code>
<del class="diff-old">section
</del>
<ins class="diff-chg">key.
The
value
</ins>
of
<del class="diff-old">a
</del>
<ins class="diff-chg">this
key,
if
present,
</ins><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
be
</ins>
<code>
<del class="diff-old">@context
</del>
<ins class="diff-chg">true
</ins></code>.<ins class="diff-chg">
This
indicates
that
array
values
of
keys
coerced
as
</ins><code><ins class="diff-chg">
@list
</ins>
</code>
<del class="diff-old">to
cause
value
arrays
</del>
<ins class="diff-chg">are
</ins>
to
be
<del class="diff-old">coerced
into
an
ordered
list.
</del>
<ins class="diff-chg">serialized
as
a
</ins><a href="#rdf-collection"><ins class="diff-chg">
List
</ins></a>.
</p>
</div>
</div>
<div id="advanced-concepts" class="section">
<h2>
<span class="secno">
4.
</span>
Advanced
Concepts
</h2>
<p>
JSON-LD
has
a
number
of
features
that
provide
functionality
above
and
beyond
the
core
functionality
described
above.
The
following
sections
outline
the
features
that
are
specific
to
JSON-LD.
</p>
<div id="external-contexts" class="section">
<h3>
<span class="secno">
4.1
</span>
<del class="diff-old">Base
URI
</del>
<ins class="diff-chg">External
Contexts
</ins>
</h3>
<p>
<ins class="diff-new">Authors
may
choose
to
declare
</ins>
JSON-LD
<del class="diff-old">allows
</del>
<a class="tref internalDFN" title="context" href="#dfn-context">
<ins class="diff-chg">context
</ins></a><ins class="diff-chg">
s
in
external
documents
to
promote
re-use
of
contexts
as
well
as
reduce
the
size
of
JSON-LD
documents.
</ins></p><p><ins class="diff-chg">
In
order
to
use
an
external
context,
an
author
</ins><em class="rfc2119" title="may"><ins class="diff-chg">
may
</ins></em><ins class="diff-chg">
specify
an
</ins>
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
<del class="diff-old">s
</del>
to
<del class="diff-old">be
specified
in
</del>
a
<del class="diff-old">relative
form.
For
subject
and
</del>
<ins class="diff-chg">valid
JSON-LD
document.
The
referenced
document
</ins><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
have
a
top-level
</ins><a class="tref internalDFN" title="json_object" href="#dfn-json_object"><ins class="diff-chg">
JSON
Object
</ins></a>.<ins class="diff-chg">
The
value
of
any
</ins><code><ins class="diff-chg">
@context
</ins></code><ins class="diff-chg">
key
within
that
</ins>
object
<del class="diff-old">IRIs,
relative
IRIs
are
resolved
against
</del>
<ins class="diff-chg">is
substituted
for
the
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-chg">
IRI
</ins></abbr><ins class="diff-chg">
within
</ins>
the
<ins class="diff-new">referencing
</ins>
document
<del class="diff-old">base
using
section
5.1
Establishing
</del>
<ins class="diff-chg">to
have
the
same
effect
as
if
the
value
were
specified
inline
within
the
referencing
document.
</ins></p><p><ins class="diff-chg">
The
following
example
demonstrates
the
use
of
an
external
context:
</ins></p><pre class="example">{
  <span class="diff">"@context": "http://example.org/json-ld-contexts/person"</span>,
<ins class="diff-chg">
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "avatar": "http://twitter.com/account/profile_image/manusporny"
}
</ins></pre><p><ins class="diff-chg">
Authors
may
also
import
multiple
contexts
or
</ins>
a
<del class="diff-old">Base
URI
</del>
<ins class="diff-chg">combination
</ins>
of
<del class="diff-old">[
RFC3986
</del>
<ins class="diff-chg">external
and
local
contexts
by
specifying
a
list
of
contexts:
</ins></p><pre class="example">{
  <span class="diff">"@context":
<ins class="diff-chg">
  [
    "http://example.org/json-ld-contexts/person",
    { "foaf": "http://xmlns.com/foaf/0.1/" },
    "http://example.org/json-ld-contexts/event"
  ]</span>
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "avatar": "http://twitter.com/account/profile_image/manusporny"
</ins>  <span class="diff">"celebrates":
<ins class="diff-chg">
  {
    "@type": "Event",
    "description": "International Talk Like a Pirate Day",
    "date": "R/2011-09-19"
  }</span>
}
</ins></pre><p><ins class="diff-chg">
Each
context
in
a
list
will
be
evaluated
in-order.
Duplicate
mappings
within
the
</ins><a class="tref internalDFN" title="context" href="#dfn-context"><ins class="diff-chg">
context
</ins>
</a>
<del class="diff-old">].
This
value
may
</del>
<ins class="diff-chg">s
</ins><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em>
be
<del class="diff-old">explicitly
set
with
</del>
<ins class="diff-chg">overwritten
on
</ins>
a
<ins class="diff-chg">last-defined-overrides
basis.
The
</ins>
context
<ins class="diff-new">list
</ins><em class="rfc2119" title="must"><ins class="diff-new">
must
</ins></em><ins class="diff-new">
contain
either
de-referenceable
</ins><a class="tref internalDFN" title="iri" href="#dfn-iri"><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr>
</a>
<del class="diff-old">using
</del>
<ins class="diff-chg">s
or
</ins><a class="tref internalDFN" title="json_object" href="#dfn-json_object"><ins class="diff-chg">
JSON
Object
</ins></a><ins class="diff-chg">
s
that
conform
to
</ins>
the
<del class="diff-old">@base
keyword.
</del>
<a class="tref internalDFN" title="context" href="#dfn-context">
<ins class="diff-chg">context
</ins></a><ins class="diff-chg">
syntax
as
described
in
this
document.
</ins>
</p>
<p>
<del class="diff-old">For
example,
if
a
JSON-LD
document
was
retrieved
from
http://manu.sporny.org/
,
relative
IRIs
would
resolve
against
that
URI:
</del>
<ins class="diff-chg">An
author
may
nest
contexts
within
</ins><a class="tref internalDFN" title="json_object" href="#dfn-json_object"><ins class="diff-chg">
JSON
object
</ins></a><ins class="diff-chg">
s,
with
the
more
deeply
nested
contexts
overriding
the
values
in
previously
defined
contexts:
</ins>
</p>
<del class="diff-old">{
  ,
  &quot;http://xmlns.com/foaf/0.1/name&quot;: &quot;Manu Sporny&quot;,
  &quot;http://xmlns.com/foaf/0.1/homepage: &quot;&quot;
</del>
<pre class="example">{
  <span class="diff">"@context":
<ins class="diff-chg">  {
    "name": "http://example.com/person#name",
    "details": "http://example.com/person#details"
  },</span>
  "<span class="diff">name</span>": "Markus",
  ...
  "details":
  {
</ins>    <span class="diff">"@context": { "name": "http://example.com/organization#name" },</span>
<ins class="diff-chg">
    "<span class="diff">name</span>": "Acme, Ltd."
  }
</ins>
}
</pre>
<p>
<del class="diff-old">This
document
uses
an
empty
@subject
,
which
resolves
to
</del>
<ins class="diff-chg">In
</ins>
the
<del class="diff-old">document
base.
However,
if
</del>
<ins class="diff-chg">example
above,
</ins>
the
<del class="diff-old">document
</del>
<code>
<ins class="diff-chg">name
</ins></code><ins class="diff-chg">
prefix
</ins>
is
<del class="diff-old">moved
to
a
different
location,
</del>
<ins class="diff-chg">overridden
in
</ins>
the
<del class="diff-old">subject
IRI
would
change.
To
prevent
this,
</del>
<ins class="diff-chg">more
deeply
nested
</ins><code><ins class="diff-chg">
details
</ins></code><ins class="diff-chg">
structure.
Note
that
this
is
rarely
</ins>
a
<ins class="diff-chg">good
authoring
practice
and
is
typically
used
when
the
JSON
object
has
legacy
applications
using
the
structure
of
the
object.
</ins></p><p><ins class="diff-chg">
External
JSON-LD
</ins>
context
<ins class="diff-chg">documents
</ins><em class="rfc2119" title="may">
may
<del class="diff-old">have
a
</del>
</em>
<ins class="diff-chg">contain
extra
information
located
outside
of
the
</ins>
<code>
<del class="diff-old">@base
</del>
<ins class="diff-chg">@context
</ins>
</code>
<del class="diff-old">mapping,
to
set
an
absolute
base
for
</del>
<ins class="diff-chg">key,
such
as
documentation
about
</ins>
the
<del class="diff-old">document
</del>
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
<ins class="diff-chg">prefix
</ins></a><ins class="diff-chg">
es
declared
</ins>
in
<del class="diff-old">spite
</del>
<ins class="diff-chg">the
document.
When
importing
a
</ins><code><ins class="diff-chg">
@context
</ins></code><ins class="diff-chg">
value
from
an
external
JSON-LD
context
document,
any
extra
information
contained
outside
</ins>
of
<del class="diff-old">where
it
actually
is
retrieved
from.
It
</del>
<ins class="diff-chg">the
</ins><code><ins class="diff-chg">
@context
</ins></code><ins class="diff-chg">
value
</ins>
<em class="rfc2119" title="must">
must
</em>
<del class="diff-old">have
a
value
of
</del>
<ins class="diff-chg">be
discarded.
It
is
also
</ins><em class="rfc2119" title="recommended"><ins class="diff-chg">
recommended
</ins></em><ins class="diff-chg">
that
</ins>
a
<del class="diff-old">simple
string
</del>
<ins class="diff-chg">human-readable
document
encoded
in
HTML+RDFa
[
</ins><cite><a class="bibref" rel="biblioentry" href="#bib-HTML-RDFA"><ins class="diff-chg">
HTML-RDFA
</ins>
</a>
<del class="diff-old">with
</del>
</cite>
<ins class="diff-chg">]
or
other
Linked
Data
compatible
format
is
served
as
well
to
explain
</ins>
the
<del class="diff-old">lexical
form
</del>
<ins class="diff-chg">correct
usage
</ins>
of
<del class="diff-old">an
absolute
IRI
.
</del>
<ins class="diff-chg">the
JSON-LD
context
document.
</ins>
</p>
<del class="diff-old">{
  ,
  &quot;@subject&quot;: &quot;about/&quot;,
  &quot;http://xmlns.com/foaf/0.1/name&quot;: &quot;Manu Sporny&quot;,
  &quot;http://xmlns.com/foaf/0.1/homepage: &quot;&quot;
}
</del>
</div>
<div id="expanded-term-definition" class="section">
<h3>
<span class="secno">
4.2
</span>
<del class="diff-old">Default
Vocabulary
</del>
<ins class="diff-chg">Expanded
Term
Definition
</ins>
</h3>
<p>
<del class="diff-old">It
is
often
common
that
all
types
and
properties
come
from
the
same
vocabulary.
JSON-LD
provides
</del>
<ins class="diff-chg">Within
</ins>
a
<del class="diff-old">way
</del>
<a class="tref internalDFN" title="context" href="#dfn-context">
<ins class="diff-chg">context
</ins></a><ins class="diff-chg">
definition,
</ins><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-chg">
term
</ins></a><ins class="diff-chg">
s
</ins><em class="rfc2119" title="may"><ins class="diff-chg">
may
</ins></em><ins class="diff-chg">
be
defined
using
an
expanded
notation
</ins>
to
<del class="diff-old">set
a
base
URI
</del>
<ins class="diff-chg">allow
for
additional
information
associated
with
the
term
</ins>
to
be
<del class="diff-old">used
for
all
properties
</del>
<ins class="diff-chg">specified
(see
</ins><a href="#type-coerceion"><ins class="diff-chg">
Type
Coercion
</ins></a>
and
<del class="diff-old">types
that
aren't
based
on
terms,
prefixes
or
absolute
IRIs.
Much
like
the
@base
keyword,
</del>
<a href="#rdf-collection">
<ins class="diff-chg">Lists
</ins></a><ins class="diff-chg">
).
</ins></p><p><ins class="diff-chg">
Instead
of
using
a
string
representation
of
an
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-chg">
IRI
</ins></abbr>,
the
<abbr title="Internationalized Resource Identifier">
<ins class="diff-new">IRI
</ins></abbr><ins class="diff-new">
is
specified
using
an
object
having
an
</ins>
<code>
<del class="diff-old">@vocab
</del>
<ins class="diff-chg">@id
</ins>
</code>
<del class="diff-old">keyword
can
</del>
<ins class="diff-chg">key.
The
value
of
this
key
</ins><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em>
be
<del class="diff-old">used
to
set
a
base
IRI
to
use
for
all
types
and
properties
that
don't
otherwise
resolve
to
</del>
an
absolute
<abbr title="Internationalized Resource Identifier">
IRI
<del class="diff-old">.
{
  
  ,
  &quot;name&quot;: &quot;Manu Sporny&quot;,
  &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
</del>
</abbr>.
</p>
<pre class="example">{
<ins class="diff-chg">  "@context": {
    "name": <span class="diff">{"@id": "http://xmlns.com/foaf/0.1/name"}</span>,
    "homepage": <span class="diff">{"@id": "http://xmlns.com/foaf/0.1/homepage"}</span>,
    "avatar": <span class="diff">{"@id": "http://xmlns.com/foaf/0.1/avatar"}</span>
  },
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "avatar": "http://twitter.com/account/profile_image/manusporny"
</ins>
}
</pre>
<p class="issue">
<ins class="diff-new">There
is
an
open
issue
(
</ins><a href="https://github.com/json-ld/json-ld.org/issues/43" target="_blank"><ins class="diff-new">
#43
</ins></a><ins class="diff-new">
)
on
allowing
non-terms
in
the
key
position
to
allow
</ins><a class="tref internalDFN" title="coercion" href="#dfn-coercion"><ins class="diff-new">
coercion
</ins></a><ins class="diff-new">
to
be
specified
for
CURIEs
or
absolute
IRIs.
</ins></p>
</div>
<div id="default-language" class="section">
<h3>
<span class="secno">
4.3
</span>
Default
Language
</h3>
<p>
JSON-LD
allows
a
default
value
to
use
as
the
language
for
<a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal">
plain
literal
</a>
s.
It
is
commonly
the
case
that
documents
are
written
using
a
single
language.
As
described
in
<a href="string-internationalization">
String
Internationalization
</a>,
a
language-tagged
literal
may
be
specified
as
follows:
</p>
<del class="diff-old">{
...
  &quot;name&quot;:
  {
    &quot;@literal&quot;: &quot;花澄&quot;,
    &quot;@language&quot;: &quot;ja&quot;
  }
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "name":
  {
    "@value": "&#33457;&#28548;",
    "@language": "ja"
  }
...
</ins>
}
</pre>
<p>
<del class="diff-old">By
specifying
</del>
<ins class="diff-chg">It
is
also
possible
to
apply
a
particular
language
code
to
all
plain
literals
by
setting
the
</ins>
<code>
@language
</code>
<del class="diff-old">within
</del>
<ins class="diff-chg">key
in
the
</ins><code><ins class="diff-chg">
@context
</ins></code>:</p><pre class="example">{
  <span class="diff">"@context:"
<ins class="diff-chg">
  {
    "@language": "ja"
  },</span>
...
  "name": <span class="diff">"&#33457;&#28548;"</span>
  "occupation": <span class="diff">"&#31185;&#23398;&#32773;"</span>
...
}
</ins></pre><p><ins class="diff-chg">
The
example
above
would
generate
</ins>
a
<del class="diff-old">context
,
multiple
language-tagged
literals
may
be
marked
up
</del>
<a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal">
<ins class="diff-chg">plain
literal
</ins></a><ins class="diff-chg">
for
</ins><em><ins class="diff-chg">
&#33457;&#28548;
</ins></em><ins class="diff-chg">
and
</ins><em><ins class="diff-chg">
&#31185;&#23398;&#32773;
</ins></em><ins class="diff-chg">
and
associate
the
</ins><code><ins class="diff-chg">
ja
</ins></code><ins class="diff-chg">
language
code
with
each
literal.
</ins></p><p><ins class="diff-chg">
It
is
possible
to
override
the
default
language
by
</ins>
using
<ins class="diff-new">the
expanded
form
of
</ins>
a
<del class="diff-old">simple
string
form:
</del>
<ins class="diff-chg">literal:
</ins>
</p>
<del class="diff-old">{
  ,
...
  &quot;name&quot;: 
...
</del>
<pre class="example">{
<ins class="diff-chg">  "@context:"
  {
     "@language": "ja"
  },
...
  "name": "&#33457;&#28548;"
  "occupation": <span class="diff">
  {
    "@value": "Scientist",
    "@language": "en"
  }</span>
...
</ins>
}
</pre>
<p>
<ins class="diff-chg">It
is
also
possible
to
override
the
default
language
and
specify
a
plain
literal
by
omitting
the
</ins><code><ins class="diff-chg">
@language
</ins></code><ins class="diff-chg">
tag
when
expressing
the
expanded
literal
value:
</ins></p><pre class="example">{
<ins class="diff-chg">
  "@context:"
  {
     "@language": "ja"
  },
...
  "name": "&#33457;&#28548;"
  "occupation": <span class="diff">
  {
    "@value": "Ninja"
  }</span>
...
}
</ins></pre></div><div id="prefixes" class="section">
<h3>
<span class="secno">
4.4
</span>
<del class="diff-old">Vocabulary
</del>
Prefixes
</h3>
<p>
Vocabulary
terms
in
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
documents
may
draw
from
a
number
of
different
Web
vocabularies.
At
times,
declaring
every
single
term
that
a
document
uses
can
require
the
developer
to
declare
tens,
if
not
hundreds
of
potential
vocabulary
terms
that
may
be
used
across
an
application.
This
is
a
concern
for
at
least
three
reasons;
the
first
is
the
cognitive
load
on
the
developer,
the
second
is
the
serialized
size
of
the
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>,
the
third
is
future-proofing
application
contexts.
In
order
to
address
these
issues,
the
concept
of
a
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>
mechanism
is
introduced.
</p>
<p>
A
<dfn title="prefix" id="dfn-prefix">
prefix
</dfn>
is
a
compact
way
of
expressing
a
base
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
to
a
<a class="tref internalDFN" title="web_vocabulary" href="#dfn-web_vocabulary">
Web
Vocabulary
</a>.
Generally,
these
prefixes
are
used
by
concatenating
the
<em>
prefix
</em>
and
a
<em>
suffix
</em>
separated
by
a
colon
(
<code>:
</code>
).
The
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>
is
a
<a class="tref internalDFN" title="term" href="#dfn-term">
term
</a>
taken
from
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
<del class="diff-old">,
</del>
</a>
<ins class="diff-chg">and
is
</ins>
a
short
string
<del class="diff-old">that
identifies
</del>
<ins class="diff-chg">identifying
</ins>
a
particular
<del class="diff-old">Web
vocabulary.
</del>
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
<ins class="diff-chg">IRI
</ins></abbr></a><ins class="diff-chg">
in
a
JSON-LD
document.
</ins>
For
example,
the
prefix
<code>
foaf
</code>
may
be
used
as
a
short
hand
for
the
Friend-of-a-Friend
Web
Vocabulary,
which
is
identified
using
the
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
<code>
http://xmlns.com/foaf/0.1/
</code>.
A
developer
may
append
any
of
the
FOAF
Vocabulary
terms
to
the
end
of
the
prefix
to
specify
a
short-hand
version
of
the
absolute
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
for
the
vocabulary
term.
For
example,
<code>
foaf:name
</code>
would
be
expanded
out
to
the
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
<code>
http://xmlns.com/foaf/0.1/name
</code>.
Instead
of
having
to
remember
and
type
out
the
entire
<del class="diff-old">IRI,
</del>
<abbr title="Internationalized Resource Identifier">
<ins class="diff-chg">IRI
</ins></abbr>,
the
developer
can
instead
use
the
prefix
in
their
JSON-LD
markup.
</p>
<p>
<ins class="diff-new">To
generate
an
</ins><a class="tref internalDFN" title="iri" href="#dfn-iri"><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr></a><ins class="diff-new">
out
of
a
</ins><code><ins class="diff-new">
prefix:suffix
</ins></code><ins class="diff-new">
construct,
the
value
is
first
split
into
a
</ins><em><ins class="diff-new">
prefix
</ins></em><ins class="diff-new">
and
</ins><em><ins class="diff-new">
suffix
</ins></em><ins class="diff-new">
at
the
first
occurrence
of
a
colon
(
</ins><code>:</code><ins class="diff-new">
).
If
the
</ins><a class="tref internalDFN" title="active_context" href="#dfn-active_context"><ins class="diff-new">
active
context
</ins></a><ins class="diff-new">
contains
a
term
mapping
for
</ins><em><ins class="diff-new">
prefix
</ins></em>,<ins class="diff-new">
an
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr><ins class="diff-new">
is
generated
by
prepending
the
mapped
</ins><em><ins class="diff-new">
prefix
</ins></em><ins class="diff-new">
to
the
(possibly
empty)
</ins><em><ins class="diff-new">
suffix
</ins></em><ins class="diff-new">
using
textual
concatenation.
If
no
prefix
mapping
is
defined,
the
value
is
used
directly
as
an
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr>.<ins class="diff-new">
If
the
prefix
is
an
underscore
(
</ins><code><ins class="diff-new">
_
</ins></code><ins class="diff-new">
),
the
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr><ins class="diff-new">
remains
unchanged.
</ins></p><p>
The
ability
to
use
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>
es
reduces
the
need
for
developers
to
declare
every
vocabulary
term
that
they
intend
to
use
in
the
JSON-LD
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>.
This
reduces
document
serialization
size
because
every
vocabulary
term
need
not
be
declared
in
the
context.
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
Prefix
</a>
also
reduce
the
cognitive
load
on
the
developer.
It
is
far
easier
to
remember
<code>
foaf:name
</code>
than
it
is
to
remember
<code>
http://xmlns.com/foaf/0.1/name
</code>.
The
use
of
prefixes
also
ensures
that
a
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
document
does
not
have
to
be
updated
in
lock-step
with
an
externally
defined
<a class="tref internalDFN" title="web_vocabulary" href="#dfn-web_vocabulary">
Web
Vocabulary
</a>.
Without
prefixes,
a
developer
would
need
to
keep
their
application
context
terms
in
lock-step
with
an
externally
defined
Web
Vocabulary.
Rather,
by
just
declaring
the
Web
Vocabulary
prefix,
one
can
use
new
terms
as
they're
declared
without
having
to
update
the
application's
JSON-LD
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>.
</p>
<p>
Consider
the
following
example:
</p>
<del class="diff-old">  {
  &quot;@context&quot;: {
    
    
  },
  &quot;@subject&quot;: &quot;http://example.org/library&quot;,
  &quot;@type&quot;: ,
  : {
    &quot;@subject&quot;: &quot;http://example.org/library/the-republic&quot;,
    &quot;@type&quot;: ,
    : &quot;Plato&quot;,
    : &quot;The Republic&quot;,
    : {
      &quot;@subject&quot;: &quot;http://example.org/library/the-republic#introduction&quot;,
      &quot;@type&quot;: ,
      : &quot;An introductory chapter on The Republic.&quot;,
      : &quot;The Introduction&quot;
    },
  },
</del>
  <pre class="example">{
<ins class="diff-chg">  "@context": {
</ins>    <span class="diff">"dc": "http://purl.org/dc/elements/1.1/",</span>
    <span class="diff">"ex": "http://example.org/vocab#"</span>
<ins class="diff-chg">
  },
  "@id": "http://example.org/library",
  "@type": <span class="diff">"ex:Library"</span>,
</ins>  <span class="diff">"ex:contains"</span>: {
<ins class="diff-chg">
    "@id": "http://example.org/library/the-republic",
    "@type": <span class="diff">"ex:Book"</span>,
</ins>    <span class="diff">"dc:creator"</span>: "Plato",
    <span class="diff">"dc:title"</span>: "The Republic",
    <span class="diff">"ex:contains"</span>: {
<ins class="diff-chg">
      "@id": "http://example.org/library/the-republic#introduction",
      "@type": <span class="diff">"ex:Chapter"</span>,
</ins>      <span class="diff">"dc:description"</span>: "An introductory chapter on The Republic.",
      <span class="diff">"dc:title"</span>: "The Introduction"
<ins class="diff-chg">
    }
  }
</ins>
}
</pre>
<p>
In
this
example,
two
different
vocabularies
are
referred
to
using
prefixes.
Those
prefixes
are
then
used
as
type
and
property
values
using
the
<code>
prefix:suffix
</code>
notation.
</p>
<p>
Prefixes,
also
known
as
CURIEs,
are
defined
more
formally
in
RDFa
Core
1.1,
<cite>
<a href="http://www.w3.org/TR/rdfa-core/#s_curies">
Section
6
<del class="diff-old">&quot;CURIE
</del>
<ins class="diff-chg">"CURIE
</ins>
Syntax
<del class="diff-old">Definition&quot;
</del>
<ins class="diff-chg">Definition"
</ins>
</a>
</cite>
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RDFA-CORE">
RDFA-CORE
</a>
</cite>
].
JSON-LD
does
not
support
the
square-bracketed
CURIE
syntax
as
the
mechanism
is
not
required
to
disambiguate
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s
in
a
JSON-LD
document
like
it
is
in
HTML
documents.
</p>
</div>
<div id="iri-expansion-within-context" class="section">
<h3>
<span class="secno">
4.5
</span>
<abbr title="Internationalized Resource Identifier">
<ins class="diff-new">IRI
</ins></abbr><ins class="diff-new">
Expansion
within
Context
</ins></h3><p><ins class="diff-new">
To
be
consistent
with
JSON-LD
in
general,
anywhere
an
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr><ins class="diff-new">
is
expected,
normal
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr><ins class="diff-new">
expansion
rules
apply
(see
</ins><a href="#iris"><ins class="diff-new">
IRIs
</ins></a><ins class="diff-new">
).
Within
a
</ins><a class="tref internalDFN" title="context" href="#dfn-context"><ins class="diff-new">
context
</ins></a><ins class="diff-new">
definition,
this
can
mean
that
terms
defined
within
a
given
context
</ins><em class="rfc2119" title="may"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
also
be
used
within
that
context,
as
long
as
there
are
no
circular
dependencies.
For
example,
it
is
common
to
use
the
</ins><code><ins class="diff-new">
xsd
</ins></code><ins class="diff-new">
namespace
when
defining
</ins><a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal"><ins class="diff-new">
typed
literal
</ins></a><ins class="diff-new">
s:
</ins></p><pre class="example">{
<ins class="diff-new">
  "@context": {
</ins>    <span class="diff">"xsd": "http://www.w3.org/2001/XMLSchema#"</span>,
<ins class="diff-new">
    "name": "http://xmlns.com/foaf/0.1/name",
    "age": {"@id": "http://xmlns.com/foaf/0.1/age", "@type": <span class="diff">"xsd:integer"</span>},
    "homepage": {"@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id"}
  },
  ...
}
</ins></pre><p><ins class="diff-new">
In
this
example,
the
</ins><code><ins class="diff-new">
xsd
</ins></code><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-new">
term
</ins></a><ins class="diff-new">
is
defined,
and
used
as
a
</ins><a class="tref internalDFN" title="prefix" href="#dfn-prefix"><ins class="diff-new">
prefix
</ins></a><ins class="diff-new">
for
the
</ins><code><ins class="diff-new">
@type
</ins></code><ins class="diff-new">
coercion
of
the
</ins><code><ins class="diff-new">
age
</ins></code><ins class="diff-new">
property.
</ins></p><p><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-new">
Term
</ins></a><ins class="diff-new">
s
</ins><em class="rfc2119" title="may"><ins class="diff-new">
may
</ins></em><ins class="diff-new">
also
be
used
when
defining
the
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-new">
IRI
</ins></abbr><ins class="diff-new">
of
another
</ins><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-new">
term
</ins></a>:</p><pre class="example">{
<ins class="diff-new">
  "@context":
  {
</ins>    <span class="diff">"foaf": "http://xmlns.com/foaf/0.1/"</span>,
<ins class="diff-new">
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "name": <span class="diff">"foaf:name"</span>,
    "age": {"@id": <span class="diff">"foaf:age"</span>, "@type": xsd:integer"},
    "homepage": {"@id": <span class="diff">"foaf:homepage"</span>, "@type": "@id"}
  },
  ...
}
</ins></pre><p><ins class="diff-new">
The
only
exception
is
that
terms
</ins><em class="rfc2119" title="must not"><ins class="diff-new">
must
not
</ins></em><ins class="diff-new">
be
used
in
a
circular
manner,
meaning
that
the
definition
of
</ins><em><ins class="diff-new">
term-1
</ins></em><ins class="diff-new">
may
not
depend
on
the
definition
of
</ins><em><ins class="diff-new">
term-2
</ins></em><ins class="diff-new">
if
</ins><em><ins class="diff-new">
term-2
</ins></em><ins class="diff-new">
also
depends
on
</ins><em><ins class="diff-new">
term-1
</ins></em>.<ins class="diff-new">
For
example,
the
following
</ins><a class="tref internalDFN" title="context" href="#dfn-context"><ins class="diff-new">
context
</ins></a><ins class="diff-new">
definition
is
illegal:
</ins></p><pre class="example">{
<ins class="diff-new">
  "@context":
  {
</ins>    <span class="diff">"term1": {"@id": "term2:foo"},
<ins class="diff-new">
    "term2": {"@id": "term1:bar"}</span>
  },
  ...
}
</ins></pre></div><div id="automatic-typing" class="section"><h3><span class="secno"><ins class="diff-new">
4.6
</ins></span>
Automatic
Typing
</h3>
<p>
Since
JSON
is
capable
of
expressing
typed
information
such
as
doubles,
integers,
and
boolean
values.
As
demonstrated
below,
JSON-LD
utilizes
that
information
to
create
<a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal">
typed
literal
</a>
s:
</p>
<del class="diff-old">{
...
  // The following two values are automatically converted to a type of xsd:double
  // and both values are equivalent to each other.
  &quot;measure:cups&quot;: ,
  &quot;measure:cups&quot;: ,
  // The following value is automatically converted to a type of xsd:double as well
  &quot;space:astronomicUnits&quot;: ,
  // The following value should never be converted to a language-native type
  &quot;measure:stones&quot;: ,
  // This value is automatically converted to having a type of xsd:integer
  &quot;chem:protons&quot;: ,
  // This value is automatically converted to having a type of xsd:boolean
  &quot;sensor:active&quot;: ,
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  // The following two values are automatically converted to a type of xsd:double
  // and both values are equivalent to each other.
  "measure:cups": <span class="diff">5.3</span>,
  "measure:cups": <span class="diff">5.3e0</span>,
  // The following value is automatically converted to a type of xsd:double as well
  "space:astronomicUnits": <span class="diff">6.5e73</span>,
  // The following value should never be converted to a language-native type
  "measure:stones": <span class="diff">{ "@value": "4.8", "@type": "xsd:decimal" }</span>,
  // This value is automatically converted to having a type of xsd:integer
  "chem:protons": <span class="diff">12</span>,
  // This value is automatically converted to having a type of xsd:boolean
  "sensor:active": <span class="diff">true</span>,
...
</ins>
}
</pre>
<p class="note">
When
dealing
with
a
number
of
modern
programming
languages,
including
JavaScript
ECMA-262,
there
is
no
distinction
between
<strong>
xsd:decimal
</strong>
and
<strong>
xsd:double
</strong>
values.
That
is,
the
<a class="tref internalDFN" title="number" href="#dfn-number">
number
</a>
<code>
5.3
</code>
and
the
<a class="tref internalDFN" title="number" href="#dfn-number">
number
</a>
<code>
5.3e0
</code>
are
treated
as
if
they
were
the
same.
When
converting
from
JSON-LD
to
a
language-native
format
and
back,
datatype
information
is
lost
in
a
number
of
these
languages.
Thus,
one
could
say
that
<code>
5.3
</code>
is
a
<strong>
xsd:decimal
</strong>
and
<code>
5.3e0
</code>
is
an
<strong>
xsd:double
</strong>
in
JSON-LD,
but
when
both
values
are
converted
to
a
language-native
format
the
datatype
difference
between
the
two
is
lost
because
the
machine-level
representation
will
almost
always
be
a
<strong>
double
</strong>.
Implementers
should
be
aware
of
this
potential
round-tripping
issue
between
<strong>
xsd:decimal
</strong>
and
<strong>
xsd:double
</strong>.
Specifically
objects
with
a
datatype
of
<strong>
xsd:decimal
</strong>
<em class="rfc2119" title="must not">
must
not
</em>
be
converted
to
a
language
native
type.
</p>
</div>
<div id="type-coercion" class="section">
<h3>
<span class="secno">
<del class="diff-old">4.6
</del>
<ins class="diff-chg">4.7
</ins>
</span>
Type
Coercion
</h3>
<p>
JSON-LD
supports
the
coercion
of
values
to
particular
data
types.
Type
<dfn title="coercion" id="dfn-coercion">
coercion
</dfn>
allows
someone
deploying
JSON-LD
to
coerce
the
incoming
or
outgoing
types
to
the
proper
data
type
based
on
a
mapping
of
data
type
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s
to
property
types.
Using
type
coercion,
<del class="diff-old">one
may
convert
simple
JSON
</del>
<ins class="diff-chg">value
representation
is
preserved
without
requiring
the
</ins>
data
<ins class="diff-new">type
</ins>
to
<del class="diff-old">properly
typed
RDF
data.
</del>
<ins class="diff-chg">be
specified
with
each
usage.
</ins></p><p><ins class="diff-chg">
Type
coercion
is
specified
within
an
</ins><a href="#expanded-term-definition"><ins class="diff-chg">
expanded
term
definition
</ins></a><ins class="diff-chg">
using
the
</ins><code><ins class="diff-chg">
@type
</ins></code><ins class="diff-chg">
key.
The
values
of
this
key
represent
datatype
IRIs
and
</ins><em class="rfc2119" title="must"><ins class="diff-chg">
must
</ins></em><ins class="diff-chg">
take
the
form
of
</ins><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-chg">
term
</ins></a>,<a class="tref internalDFN" title="prefix" href="#dfn-prefix"><ins class="diff-chg">
prefix
</ins></a>:suffix,<ins class="diff-chg">
absolute
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-chg">
IRI
</ins></abbr><ins class="diff-chg">
or
the
keyword
</ins><code><ins class="diff-chg">
@id
</ins></code>.<ins class="diff-chg">
Specifying
</ins><code><ins class="diff-chg">
@id
</ins></code><ins class="diff-chg">
indicates
that
within
the
body
of
a
JSON-LD
document,
string
values
of
keys
coerced
as
</ins><code><ins class="diff-chg">
@id
</ins></code><ins class="diff-chg">
are
to
be
interpreted
as
</ins><a class="tref internalDFN" title="iri" href="#dfn-iri"><abbr title="Internationalized Resource Identifier"><ins class="diff-chg">
IRI
</ins></abbr></a><ins class="diff-chg">
s,
or
labeled
nodes
and
are
subject
to
</ins><abbr title="Internationalized Resource Identifier"><ins class="diff-chg">
IRI
</ins></abbr><ins class="diff-chg">
expansion.
</ins></p><p><a class="tref internalDFN" title="term" href="#dfn-term"><ins class="diff-chg">
Terms
</ins></a><ins class="diff-chg">
or
</ins><a class="tref internalDFN" title="prefix" href="#dfn-prefix"><ins class="diff-chg">
prefixes
</ins></a><ins class="diff-chg">
used
as
the
value
of
a
</ins><code><ins class="diff-chg">
@type
</ins></code><ins class="diff-chg">
key
</ins><em class="rfc2119" title="may"><ins class="diff-chg">
may
</ins></em><ins class="diff-chg">
be
defined
within
the
same
context.
</ins>
</p>
<p>
The
example
below
demonstrates
how
a
JSON-LD
author
can
coerce
values
to
<a class="tref internalDFN" title="plain_literal" href="#dfn-plain_literal">
plain
literal
</a>
s,
<a class="tref internalDFN" title="typed_literal" href="#dfn-typed_literal">
typed
literal
</a>
<del class="diff-old">s
</del>
<ins class="diff-chg">s,
IRIs
</ins>
and
<del class="diff-old">IRIs.
</del>
<ins class="diff-chg">lists.
</ins>
</p>
<del class="diff-old">{
  &quot;@context&quot;:
  {
     &quot;rdf&quot;: &quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;,
     &quot;xsd&quot;: &quot;http://www.w3.org/2001/XMLSchema#&quot;,
     &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
     &quot;age&quot;: &quot;http://xmlns.com/foaf/0.1/age&quot;,
     &quot;homepage&quot;: &quot;http://xmlns.com/foaf/0.1/homepage&quot;,
     &quot;@coerce&quot;:
     {
        &quot;xsd:integer&quot;: &quot;age&quot;,
        &quot;@iri&quot;: &quot;homepage&quot;
     }
  },
  &quot;name&quot;: &quot;John Smith&quot;,
  &quot;age&quot;: ,
  &quot;homepage&quot;: 
</del>
<pre class="example">{
<ins class="diff-chg">  "@context":
  {
     "xsd": "http://www.w3.org/2001/XMLSchema#",
     "name": "http://xmlns.com/foaf/0.1/name",
     "age": <span class="diff">{"@id": "http://xmlns.com/foaf/0.1/age", "@type": "xsd:integer"}</span>,
     "homepage": <span class="diff">{"@id": "http://xmlns.com/foaf/0.1/homepage", "@type": "@id"}</span>
  },
  "name": "John Smith",
  "age": <span class="diff">"41"</span>,
  "homepage": <span class="diff">"http://example.org/home/"</span>
</ins>
}
</pre>
<p>
The
example
above
would
generate
the
following
<del class="diff-old">triples:
</del>
<ins class="diff-chg">turtle:
</ins>
</p>
<del class="diff-old">_:bnode1
   &lt;http://xmlns.com/foaf/0.1/name&gt;
      &quot;John Smith&quot; .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/age&gt;
      &quot;41&quot;^^http://www.w3.org/2001/XMLSchema#integer .
_:bnode1
   &lt;http://xmlns.com/foaf/0.1/homepage&gt;
&lt;http://example.org/home/&gt;
</del>
<pre class="example">@prefix xsd: &lt;http://www.w3.org/2001/XMLSchema#&gt; .
<ins class="diff-chg">
[ foaf:name "John Smith";
  foaf:age  "41"^^xsd:integer;
  foaf:homepage &lt;http://example.org/home&gt;
]
</ins>
.
</pre>
<del class="diff-old">The
mechanism
for
type
coercion
is
still
being
debated.
It
may
be
that
the
key/value
positions
are
swapped,
yielding
a
@context
such
as
the
following:
{
  &quot;@context&quot;: {
    &quot;rdf&quot;: &quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;,
    &quot;xsd&quot;: &quot;http://www.w3.org/2001/XMLSchema#&quot;,
    &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
    &quot;age&quot;: &quot;http://xmlns.com/foaf/0.1/age&quot;,
    &quot;homepage&quot;: &quot;http://xmlns.com/foaf/0.1/homepage&quot;,
    &quot;currentProject&quot;: &quot;http://xmlns.com/foaf/0.1/currentProject&quot;,
    &quot;@coerce&quot;: {
      &quot;age&quot;: &quot;xsd:integer&quot;,
      &quot;homepage&quot;: &quot;@iri&quot;,
      &quot;currentProject&quot;: [&quot;@iri&quot;, &quot;@list&quot;]
     }
  },
  ...
}
An
alternative
is
to
merge
the
coercion
into
term
definitions:
{
  &quot;@context&quot;:
  {
    &quot;rdf&quot;: &quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;,
    &quot;xsd&quot;: &quot;http://www.w3.org/2001/XMLSchema#&quot;,
    &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
    &quot;age&quot;: ,
    &quot;homepage&quot;: ,
    &quot;currentProject&quot;: ,
  },
  ...
}
</del>
</div>
<div id="chaining" class="section">
<h3>
<span class="secno">
<del class="diff-old">4.7
</del>
<ins class="diff-chg">4.8
</ins>
</span>
Chaining
</h3>
<p>
Object
<dfn title="chaining" id="dfn-chaining">
chaining
</dfn>
is
a
JSON-LD
feature
that
allows
an
author
to
use
the
definition
of
JSON-LD
objects
as
<a class="tref internalDFN" title="property" href="#dfn-property">
property
</a>
values.
This
is
a
commonly
used
mechanism
for
creating
a
parent-child
relationship
between
two
<a class="tref internalDFN" title="subject" href="#dfn-subject">
subject
</a>
s.
</p>
<p>
The
example
shows
an
two
subjects
related
by
a
property
from
the
first
subject:
</p>
<del class="diff-old">  {
...
  &quot;name&quot;: &quot;Manu Sporny&quot;,
  &quot;&quot;: {
    &quot;&quot;,
    &quot;&quot;,
  }
...
</del>
  <pre class="example">{
<ins class="diff-chg">...
  "name": "Manu Sporny",
  "<span class="diff">knows</span>": {
    "<span class="diff">@type</span>": "<span class="diff">Person</span>",
    "<span class="diff">name</span>": "<span class="diff">Gregg Kellogg</span>",
  }
...
</ins>
}
</pre>
<p>
An
object
definition,
like
the
one
used
above,
<em class="rfc2119" title="may">
may
</em>
be
used
as
a
JSON
value
at
any
point
in
JSON-LD.
</p>
</div>
<div id="identifying-unlabeled-nodes" class="section">
<h3>
<span class="secno">
<del class="diff-old">4.8
</del>
<ins class="diff-chg">4.9
</ins>
</span>
Identifying
Unlabeled
Nodes
</h3>
<p>
At
times,
it
becomes
necessary
to
be
able
to
express
information
without
being
able
to
specify
the
subject.
Typically,
this
type
of
node
is
called
an
unlabeled
node
or
a
blank
node.
In
JSON-LD,
unlabeled
node
identifiers
are
automatically
created
if
a
subject
is
not
specified
using
the
<code>
<del class="diff-old">@subject
</del>
<ins class="diff-chg">@id
</ins>
</code>
keyword.
However,
authors
may
provide
identifiers
for
unlabeled
nodes
by
using
the
special
<code>
_
</code>
(underscore)
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>.
This
allows
to
reference
the
node
locally
within
the
document
but
not
in
an
external
document.
</p>
<del class="diff-old">{
...
  &quot;@subject&quot;: &quot;&quot;,
...
</del>
<pre class="example">{
<ins class="diff-chg">...
  "@id": "<span class="diff">_:foo</span>",
...
</ins>
}
</pre>
<p>
The
example
above
would
set
the
subject
to
<code>
_:foo
</code>,
which
can
then
be
used
later
on
in
the
JSON-LD
markup
to
refer
back
to
the
unlabeled
node.
This
practice,
however,
is
usually
frowned
upon
when
generating
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>.
If
a
developer
finds
that
they
refer
to
the
unlabeled
node
more
than
once,
they
should
consider
naming
the
node
using
a
resolve-able
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>.
</p>
</div>
<div id="aliasing-keywords" class="section">
<h3>
<span class="secno">
<del class="diff-old">4.9
</del>
<ins class="diff-chg">4.10
</ins>
</span>
Aliasing
Keywords
</h3>
<p>
JSON-LD
allows
all
of
the
syntax
keywords,
except
for
<code>
@context
</code>,
to
be
aliased.
This
feature
allows
more
legacy
JSON
content
to
be
supported
by
JSON-LD.
It
also
allows
developers
to
design
domain-specific
implementations
using
only
the
JSON-LD
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>.
</p>
<del class="diff-old">{
  &quot;@context&quot;:
  {
     ,
     ,
     &quot;name&quot;: &quot;http://schema.org/name&quot;
  },
  &quot;url&quot;: &quot;http://example.com/about#gregg&quot;,
  &quot;a&quot;: &quot;http://schema.org/Person&quot;,
  &quot;name&quot;: &quot;Gregg Kellogg&quot;
</del>
<pre class="example">{
<ins class="diff-chg">  "@context":
  {
</ins>     <span class="diff">"url": "@id"</span>,
     <span class="diff">"a": "@type"</span>,
<ins class="diff-chg">
     "name": "http://schema.org/name"
  },
  "url": "http://example.com/about#gregg",
  "a": "http://schema.org/Person",
  "name": "Gregg Kellogg"
</ins>
}
</pre>
<p>
In
the
example
above,
the
<code>
<del class="diff-old">@subject
</del>
<ins class="diff-chg">@id
</ins>
</code>
and
<code>
@type
</code>
keywords
have
been
given
the
aliases
<strong>
url
</strong>
and
<strong>
a
</strong>,
respectively.
</p>
</div>
</div>
<div class="appendix section" id="markup-examples">
<h2>
<span class="secno">
<del class="diff-old">5.
</del>
<ins class="diff-chg">A.
</ins>
</span>
<del class="diff-old">Using
JSON-LD
for
RDF
</del>
<ins class="diff-chg">Markup
Examples
</ins>
</h2>
<p>
JSON-LD
is
a
specification
for
representing
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
in
JSON.
A
common
way
of
working
with
Linked
Data
is
through
<dfn title="rdf" id="dfn-rdf">
RDF
</dfn>,
the
Resource
Description
Framework.
RDF
can
be
expressed
using
JSON-LD
by
associating
JSON-LD
concepts
such
as
<code>
<del class="diff-old">@subject
</del>
<ins class="diff-chg">@id
</ins>
</code>
and
<code>
@type
</code>
with
the
equivalent
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
s
in
RDF.
Further
information
about
RDF
may
be
found
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RDF-PRIMER">
RDF-PRIMER
</a>
</cite>
].
</p>
<p>
<del class="diff-old">Some
examples
of
encoding
RDF
into
JSON-LD
may
be
found
in
Appendix
A
.
Details
of
transforming
JSON-LD
into
RDF
are
defined
in
[
JSON-LD-API
].
A.
Markup
Examples
</del>
The
JSON-LD
markup
examples
below
demonstrate
how
JSON-LD
can
be
used
to
express
semantic
data
marked
up
in
other
languages
such
as
<ins class="diff-new">RDF/XML,
Turtle,
</ins>
RDFa,
Microformats,
and
Microdata.
These
sections
are
merely
provided
as
proof
that
JSON-LD
is
very
flexible
in
what
it
can
express
across
different
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
approaches.
<ins class="diff-new">Details
of
transforming
JSON-LD
into
RDF
are
defined
in
[
</ins><cite><a class="bibref" rel="biblioentry" href="#bib-JSON-LD-API"><ins class="diff-new">
JSON-LD-API
</ins></a></cite><ins class="diff-new">
].
</ins>
</p>
<div id="turtle" class="section">
<h3>
<span class="secno">
A.1
</span>
Turtle
</h3>
<p>
The
following
are
examples
of
representing
<a class="tref internalDFN" title="rdf" href="#dfn-rdf">
RDF
</a>
as
expressed
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-TURTLE">
TURTLE
</a>
</cite>
]
into
JSON-LD.
</p>
<div id="prefix-definitions" class="section">
<h4>
<span class="secno">
A.1.1
</span>
Prefix
<del class="diff-old">and
Base
</del>
definitions
</h4>
<p>
The
JSON-LD
context
has
direct
equivalents
for
<ins class="diff-new">the
</ins>
Turtle
<code>
<del class="diff-old">@base
and
</del>
@prefix
</code>
<del class="diff-old">expressions:
</del>
<ins class="diff-chg">declaration:
</ins>
</p>
<del class="diff-old">@base &lt;http://manu.sporny.org/&gt; .
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
&lt;#me&gt; a foaf:Person;
  foaf:name &quot;Manu Sporny&quot;;
</del>
<pre class="example">@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
<ins class="diff-chg">
&lt;http://manu.sporny.org/#me&gt; a foaf:Person;
  foaf:name "Manu Sporny";
</ins>
foaf:homepage
<del class="diff-old">&lt;&gt;
</del>
<ins class="diff-chg">&lt;http://manu.sporny.org/&gt;
</ins>
.
</pre>
<del class="diff-old">{
  &quot;@context&quot;: {
    &quot;@base&quot;:  &quot;http://manu.sporny.org/&quot;,
    &quot;foaf&quot;:   &quot;http://xmlns.com/foaf/0.1/&quot;
  },
  &quot;@subject&quot;:       &quot;#me&quot;,
  &quot;@type&quot;:          &quot;foaf:Person&quot;,
  &quot;foaf:name&quot;:      &quot;Manu Sporny&quot;,
  &quot;foaf:homepage&quot;:  {&quot;@iri&quot;: &quot;&quot;}
</del>
<pre class="example">{
<ins class="diff-chg">  "@context": {
    "foaf":   "http://xmlns.com/foaf/0.1/"
  },
  "@id":            "http://manu.sporny.org/#me",
  "@type":          "foaf:Person",
  "foaf:name":      "Manu Sporny",
  "foaf:homepage":  { "@id": "http://manu.sporny.org/" }
}
</ins></pre><div class="note"><p><ins class="diff-chg">
JSON-LD
has
no
equivalent
for
the
Turtle
</ins><code><ins class="diff-chg">
@base
</ins></code><ins class="diff-chg">
declaration.
Authors
could,
of
course,
use
a
prefix
definition
to
resolve
relative
IRIs.
For
example,
an
empty
prefix
could
be
used
to
get
a
similar
effect
to
</ins><code><ins class="diff-chg">
@base
</ins></code>:</p><pre class="example">{
<ins class="diff-chg">
  "@context": {
</ins>    <span class="diff">"":       "http://manu.sporny.org/",</span>
<ins class="diff-chg">
    "foaf":   "http://xmlns.com/foaf/0.1/"
  },
  "@id":            <span class="diff">":#me"</span>,
  "@type":          "foaf:Person",
  "foaf:name":      "Manu Sporny",
  "foaf:homepage":  { "@id": <span class="diff">":" </span>}
</ins>
}
</pre>
</div>
</div>
<div id="chaining-1" class="section">
<h4>
<span class="secno">
A.1.2
</span>
Chaining
</h4>
<p>
Both
Turtle
and
JSON-LD
allow
chaining
of
objects,
although
Turtle
only
allows
chaining
of
objects
which
use
nlank
node
identifiers.
</p>
</div>
<del class="diff-old">@base &lt;http://manu.sporny.org/&gt; .
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
&lt;#me&gt; a foaf:Person;
  foaf:name &quot;Manu Sporny&quot;;
</del>
<pre class="example">@base &lt;http://manu.sporny.org/&gt; .
<ins class="diff-chg">@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .

&lt;#me&gt; a foaf:Person;
  foaf:name "Manu Sporny";
</ins>
foaf:knows
[
a
foaf:Person;
foaf:name
<del class="diff-old">&quot;Gregg
Kellogg&quot;
</del>
<ins class="diff-chg">"Gregg
Kellogg"
</ins>
]
.
</pre>
<del class="diff-old">{
  &quot;@context&quot;: {
    &quot;@base&quot;:  &quot;http://manu.sporny.org/&quot;,
    &quot;foaf&quot;:   &quot;http://xmlns.com/foaf/0.1/&quot;
  },
  &quot;@subject&quot;:       &quot;#me&quot;,
  &quot;@type&quot;:          &quot;foaf:Person&quot;,
  &quot;foaf:name&quot;:      &quot;Manu Sporny&quot;,
  &quot;foaf:knows&quot;:  {
    &quot;@type&quot;:          &quot;foaf:Person&quot;,
    &quot;foaf:name&quot;:      &quot;Gregg Kellogg&quot;
  }
</del>
<pre class="example">{
<ins class="diff-chg">  "@context": {
    "":       "http://manu.sporny.org/",
    "foaf":   "http://xmlns.com/foaf/0.1/"
  },
  "@id":            ":#me",
  "@type":          "foaf:Person",
  "foaf:name":      "Manu Sporny",
  "foaf:knows": {
    "@type":        "foaf:Person",
    "foaf:name":    "Gregg Kellogg"
  }
</ins>
}
</pre>
<div id="lists" class="section">
<h4>
<span class="secno">
A.1.3
</span>
Lists
</h4>
<p>
Both
JSON-LD
and
Turtle
can
represent
sequential
lists
of
values.
</p>
<del class="diff-old">@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
&lt;http://example.org/people#joebob&gt; a foaf:Person;
  foaf:name &quot;Joe Bob&quot;;
</del>
<pre class="example">@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
<ins class="diff-chg">
&lt;http://example.org/people#joebob&gt; a foaf:Person;
  foaf:name "Joe Bob";
</ins>
foaf:nick
(
<del class="diff-old">&quot;joe&quot;
&quot;bob&quot;
&quot;jaybee&quot;)
</del>
<ins class="diff-chg">"joe"
"bob"
"jaybee")
</ins>
.
</pre>
<del class="diff-old">{
  &quot;@context&quot;: {
    &quot;@base&quot;:  &quot;http://manu.sporny.org/&quot;,
    &quot;foaf&quot;:   &quot;http://xmlns.com/foaf/0.1/&quot;
  },
  &quot;@subject&quot;:       &quot;http://example.org/people#joebob&quot;,
  &quot;@type&quot;:          &quot;foaf:Person&quot;,
  &quot;foaf:name&quot;:      &quot;Joe Bob&quot;,
  &quot;foaf:nick&quot;:      {&quot;@list&quot;: [&quot;joe&quot;, &quot;bob&quot;, &quot;jaybe&quot;]}
</del>
<pre class="example">{
<ins class="diff-chg">  "@context": {
    "foaf":   "http://xmlns.com/foaf/0.1/"
  },
  "@id":        "http://example.org/people#joebob",
  "@type":      "foaf:Person",
  "foaf:name":  "Joe Bob",
  "foaf:nick":  { "@list": [ "joe", "bob", "jaybe" ] }
</ins>
}
</pre>
</div>
</div>
<div id="rdfa" class="section">
<h3>
<span class="secno">
A.2
</span>
RDFa
</h3>
<p>
The
following
example
describes
three
people
with
their
respective
names
and
homepages.
</p>
<del class="diff-old">&gt;
   &lt;ul&gt;
      &lt;li &gt;
        &lt;a &gt;Bob&lt;/a&gt;
      &lt;/li&gt;
      &lt;li &gt;
        &lt;a &gt;Eve&lt;/a&gt;
      &lt;/li&gt;
      &lt;li &gt;
        &lt;a &gt;Manu&lt;/a&gt;
      &lt;/li&gt;
   &lt;/ul&gt;
</del>
<pre class="example">&lt;div <span class="diff">prefix="foaf: http://xmlns.com/foaf/0.1/"</span>&gt;
<ins class="diff-chg">   &lt;ul&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/bob/" property="foaf:name" </span>&gt;Bob&lt;/a&gt;
      &lt;/li&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/eve/" property="foaf:name" </span>&gt;Eve&lt;/a&gt;
      &lt;/li&gt;
      &lt;li <span class="diff">typeof="foaf:Person"</span>&gt;
        &lt;a <span class="diff">rel="foaf:homepage" href="http://example.com/manu/" property="foaf:name" </span>&gt;Manu&lt;/a&gt;
      &lt;/li&gt;
   &lt;/ul&gt;
</ins>
&lt;/div&gt;
</pre>
<p>
An
example
JSON-LD
implementation
is
described
below,
however,
there
are
other
ways
to
mark-up
this
information
such
that
the
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
is
not
repeated.
</p>
<del class="diff-old">{
  &quot;@context&quot;: { &quot;foaf&quot;: &quot;http://xmlns.com/foaf/0.1/&quot;},
  &quot;@subject&quot;: [
   {
     &quot;@subject&quot;: &quot;_:bnode1&quot;,
     &quot;@type&quot;: &quot;foaf:Person&quot;,
     &quot;foaf:homepage&quot;: &quot;http://example.com/bob/&quot;,
     &quot;foaf:name&quot;: &quot;Bob&quot;
   },
   {
     &quot;@subject&quot;: &quot;_:bnode2&quot;,
     &quot;@type&quot;: &quot;foaf:Person&quot;,
     &quot;foaf:homepage&quot;: &quot;http://example.com/eve/&quot;,
     &quot;foaf:name&quot;: &quot;Eve&quot;
   },
   {
     &quot;@subject&quot;: &quot;_:bnode3&quot;,
     &quot;@type&quot;: &quot;foaf:Person&quot;,
     &quot;foaf:homepage&quot;: &quot;http://example.com/manu/&quot;,
     &quot;foaf:name&quot;: &quot;Manu&quot;
   }
  ]
</del>
<pre class="example">{
<ins class="diff-chg">  "@context": { "foaf": "http://xmlns.com/foaf/0.1/" },
  "@id": [
    {
      "@id": "_:bnode1",
      "@type": "foaf:Person",
      "foaf:homepage": "http://example.com/bob/",
      "foaf:name": "Bob"
    },
    {
      "@id": "_:bnode2",
      "@type": "foaf:Person",
      "foaf:homepage": "http://example.com/eve/",
      "foaf:name": "Eve"
    },
    {
      "@id": "_:bnode3",
      "@type": "foaf:Person",
      "foaf:homepage": "http://example.com/manu/",
      "foaf:name": "Manu"
    }
  ]
</ins>
}
</pre>
</div>
<div id="microformats" class="section">
<h3>
<span class="secno">
A.3
</span>
Microformats
</h3>
<p>
The
following
example
uses
a
simple
Microformats
hCard
example
to
express
how
the
Microformat
is
represented
in
JSON-LD.
</p>
<del class="diff-old">&lt;div class=&quot;vcard&quot;&gt;
 &lt;a class=&quot;url fn&quot; href=&quot;http://tantek.com/&quot;&gt;Tantek Çelik&lt;/a&gt;
</del>
<pre class="example">&lt;div class="vcard"&gt;
<ins class="diff-chg"> &lt;a class="url fn" href="http://tantek.com/"&gt;Tantek �elik&lt;/a&gt;
</ins>
&lt;/div&gt;
</pre>
<p>
The
representation
of
the
hCard
expresses
the
Microformat
terms
in
the
<a class="tref internalDFN" title="context" href="#dfn-context">
context
</a>
and
uses
them
directly
for
the
<code>
url
</code>
and
<code>
fn
</code>
properties.
Also
note
that
the
Microformat
to
JSON-LD
processor
has
generated
the
proper
URL
type
for
<code>
http://tantek.com
</code>.
</p>
<del class="diff-old">{
  &quot;@context&quot;:
  {
    &quot;vcard&quot;: &quot;http://microformats.org/profile/hcard#vcard&quot;,
    &quot;url&quot;: &quot;http://microformats.org/profile/hcard#url&quot;,
    &quot;fn&quot;: &quot;http://microformats.org/profile/hcard#fn&quot;,
    &quot;@coerce&quot;: { &quot;@iri&quot;: &quot;url&quot; }
  },
  &quot;@subject&quot;: &quot;_:bnode1&quot;,
  &quot;@type&quot;: &quot;vcard&quot;,
  &quot;url&quot;: &quot;http://tantek.com/&quot;,
  &quot;fn&quot;: &quot;Tantek Çelik&quot;
</del>
<pre class="example">{
<ins class="diff-chg">  "@context":
  {
    "vcard": "http://microformats.org/profile/hcard#vcard",
    "url": {"@id": "http://microformats.org/profile/hcard#url", "@type": "@id"},
    "fn": "http://microformats.org/profile/hcard#fn"
  },
  "@id": "_:bnode1",
  "@type": "vcard",
  "url": "http://tantek.com/",
  "fn": "Tantek �elik"
</ins>
}
</pre>
</div>
<div id="microdata" class="section">
<h3>
<span class="secno">
A.4
</span>
Microdata
</h3>
<p>
The
<del class="diff-old">Microdata
</del>
<ins class="diff-chg">microdata
</ins>
example
below
expresses
book
information
as
a
<del class="diff-old">Microdata
</del>
<ins class="diff-chg">microdata
</ins>
Work
item.
</p>
<del class="diff-old">&lt;dl itemscope
    itemtype=&quot;http://purl.org/vocab/frbr/core#Work&quot;
    itemid=&quot;http://purl.oreilly.com/works/45U8QJGZSQKDH8N&quot;&gt;
 &lt;dt&gt;Title&lt;/dt&gt;
 &lt;dd&gt;&lt;cite itemprop=&quot;http://purl.org/dc/terms/title&quot;&gt;Just a Geek&lt;/cite&gt;&lt;/dd&gt;
 &lt;dt&gt;By&lt;/dt&gt;
 &lt;dd&gt;&lt;span itemprop=&quot;http://purl.org/dc/terms/creator&quot;&gt;Wil Wheaton&lt;/span&gt;&lt;/dd&gt;
 &lt;dt&gt;Format&lt;/dt&gt;
 &lt;dd itemprop=&quot;http://purl.org/vocab/frbr/core#realization&quot;
     itemscope
     itemtype=&quot;http://purl.org/vocab/frbr/core#Expression&quot;
     itemid=&quot;http://purl.oreilly.com/products/9780596007683.BOOK&quot;&gt;
  &lt;link itemprop=&quot;http://purl.org/dc/terms/type&quot; href=&quot;http://purl.oreilly.com/product-types/BOOK&quot;&gt;
  Print
 &lt;/dd&gt;
 &lt;dd itemprop=&quot;http://purl.org/vocab/frbr/core#realization&quot;
     itemscope
     itemtype=&quot;http://purl.org/vocab/frbr/core#Expression&quot;
     itemid=&quot;http://purl.oreilly.com/products/9780596802189.EBOOK&quot;&gt;
  &lt;link itemprop=&quot;http://purl.org/dc/terms/type&quot; href=&quot;http://purl.oreilly.com/product-types/EBOOK&quot;&gt;
  Ebook
 &lt;/dd&gt;
</del>
<pre class="example">&lt;dl itemscope
<ins class="diff-chg">    itemtype="http://purl.org/vocab/frbr/core#Work"
    itemid="http://purl.oreilly.com/works/45U8QJGZSQKDH8N"&gt;
 &lt;dt&gt;Title&lt;/dt&gt;
 &lt;dd&gt;&lt;cite itemprop="http://purl.org/dc/terms/title"&gt;Just a Geek&lt;/cite&gt;&lt;/dd&gt;
 &lt;dt&gt;By&lt;/dt&gt;
 &lt;dd&gt;&lt;span itemprop="http://purl.org/dc/terms/creator"&gt;Wil Wheaton&lt;/span&gt;&lt;/dd&gt;
 &lt;dt&gt;Format&lt;/dt&gt;
 &lt;dd itemprop="http://purl.org/vocab/frbr/core#realization"
     itemscope
     itemtype="http://purl.org/vocab/frbr/core#Expression"
     itemid="http://purl.oreilly.com/products/9780596007683.BOOK"&gt;
  &lt;link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/BOOK"&gt;
  Print
 &lt;/dd&gt;
 &lt;dd itemprop="http://purl.org/vocab/frbr/core#realization"
     itemscope
     itemtype="http://purl.org/vocab/frbr/core#Expression"
     itemid="http://purl.oreilly.com/products/9780596802189.EBOOK"&gt;
  &lt;link itemprop="http://purl.org/dc/terms/type" href="http://purl.oreilly.com/product-types/EBOOK"&gt;
  Ebook
 &lt;/dd&gt;
</ins>
&lt;/dl&gt;
</pre>
<p>
Note
that
the
JSON-LD
representation
of
the
<del class="diff-old">Microdata
</del>
<ins class="diff-chg">microdata
</ins>
information
stays
true
to
the
desires
of
the
<del class="diff-old">Microdata
</del>
<ins class="diff-chg">microdata
</ins>
community
to
avoid
contexts
and
instead
refer
to
items
by
their
full
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<del class="diff-old">IRI
.
[
  {
    &quot;@subject&quot;: &quot;http://purl.oreilly.com/works/45U8QJGZSQKDH8N&quot;,
    &quot;@type&quot;: &quot;http://purl.org/vocab/frbr/core#Work&quot;,
    &quot;http://purl.org/dc/terms/title&quot;: &quot;Just a Geek&quot;,
    &quot;http://purl.org/dc/terms/creator&quot;: &quot;Whil Wheaton&quot;,
    &quot;http://purl.org/vocab/frbr/core#realization&quot;:
      [&quot;http://purl.oreilly.com/products/9780596007683.BOOK&quot;, &quot;http://purl.oreilly.com/products/9780596802189.EBOOK&quot;]
  },
  {
    &quot;@subject&quot;: &quot;http://purl.oreilly.com/products/9780596007683.BOOK&quot;,
    &quot;@type&quot;: &quot;http://purl.org/vocab/frbr/core#Expression&quot;,
    &quot;http://purl.org/dc/terms/type&quot;: &quot;http://purl.oreilly.com/product-types/BOOK&quot;
  },
  {
    &quot;@subject&quot;: &quot;http://purl.oreilly.com/products/9780596802189.EBOOK&quot;,
    &quot;@type&quot;: &quot;http://purl.org/vocab/frbr/core#Expression&quot;,
    &quot;http://purl.org/dc/terms/type&quot;: &quot;http://purl.oreilly.com/product-types/EBOOK&quot;
  }
]
</del>
<del class="diff-old">B.
Mashing
Up
Vocabularies
Developers
would
also
benefit
by
allowing
other
vocabularies
to
be
used
automatically
with
their
JSON
API.
There
are
over
200
Web
Vocabulary
Documents
that
are
available
for
use
on
the
Web
today.
Some
of
these
vocabularies
are:
RDF
-
for
describing
information
about
objects
and
concepts
on
the
Web.
RDFS
-
for
expressing
things
like
labels
and
comments.
XSD
-
for
specifying
basic
types
like
strings,
integers,
dates
and
times.
Dublin
Core
-
for
describing
creative
works.
FOAF
-
for
describing
social
networks.
Calendar
-
for
specifying
events.
SIOC
-
for
describing
discussions
on
blogs
and
websites.
CCrel
-
for
describing
Creative
Commons
and
other
types
of
licenses.
GEO
-
for
describing
geographic
location.
VCard
-
for
describing
organizations
and
people.
DOAP
-
for
describing
projects.
You
can
use
these
vocabularies
in
combination,
like
so:
{
  &quot;&quot;,
  &quot;&quot;: &quot;Manu Sporny&quot;,
  &quot;&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
Developers
can
also
specify
their
own
Vocabulary
documents
by
modifying
the
active
context
in-line
using
the
@context
keyword,
like
so:
{
  ,
  &quot;@type&quot;: &quot;foaf:Person&quot;,
  &quot;foaf:name&quot;: &quot;Manu Sporny&quot;,
  &quot;foaf:homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  &quot;sioc:avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;,
  &quot;myvocab:personality&quot;: &quot;friendly&quot;
}
The
@context
keyword
is
used
to
change
how
the
JSON-LD
processor
evaluates
key-value
pairs.
In
this
case,
it
was
used
to
map
one
string
('myvocab')
to
another
string,
which
is
interpreted
as
a
</del>
<abbr title="Internationalized Resource Identifier">
IRI
<del class="diff-old">.
In
the
example
above,
the
myvocab
string
is
replaced
with
&quot;
http://example.org/myvocab#
&quot;
when
it
is
detected.
In
the
example
above,
&quot;
myvocab:personality
&quot;
would
expand
to
&quot;
http://example.org/myvocab#personality
&quot;.
This
mechanism
is
a
short-hand,
called
a
Web
Vocabulary
prefix
,
and
provides
developers
an
unambiguous
way
to
map
any
JSON
value
to
RDF.
C.
IANA
Considerations
This
section
is
included
merely
for
standards
community
review
and
will
be
submitted
to
the
Internet
Engineering
Steering
Group
if
this
specification
becomes
a
W3C
Recommendation.
Type
name:
application
Subtype
name:
ld+json
Required
parameters:
None
Optional
parameters:
form
Determines
the
serialization
form
for
the
JSON-LD
document.
Valid
values
include;
compacted
,
expanded
,
framed
,
and
normalized
.
Other
values
are
allowed,
but
must
be
pre-pended
with
a
x-
string
until
they
are
clearly
defined
by
a
stable
specification.
If
no
form
is
specified
in
an
HTTP
request
header
to
a
responding
application,
such
as
a
Web
server,
the
application
may
choose
any
form.
If
no
form
is
specified
for
a
receiving
application,
the
form
must
not
be
assumed
to
take
any
particular
form.
It
is
currently
being
discussed
to
remove
form=framed
from
this
specification
as
there
are
several
issues
with
it.
Encoding
considerations:
The
same
as
the
application/json
MIME
media
type.
Security
considerations:
Since
JSON-LD
is
intended
to
be
a
pure
data
exchange
format
for
directed
graphs,
the
serialization
should
not
be
passed
through
a
code
execution
mechanism
such
as
JavaScript's
eval()
function.
It
is
recommended
that
a
conforming
parser
does
not
attempt
to
directly
evaluate
the
JSON-LD
serialization
and
instead
purely
parse
the
input
into
a
language-native
data
structure.
Interoperability
considerations:
Not
Applicable
Published
specification:
The
JSON-LD
specification.
Applications
that
use
this
media
type:
Any
programming
environment
that
requires
the
exchange
of
directed
graphs.
Implementations
of
JSON-LD
have
been
created
for
JavaScript,
Python,
Ruby,
PHP
and
C++.
Additional
information:
Magic
number(s):
Not
Applicable
File
extension(s):
.jsonld
Macintosh
file
type
code(s):
TEXT
Person
&amp;
email
address
to
contact
for
further
information:
Manu
Sporny
&lt;msporny@digitalbazaar.com&gt;
Intended
usage:
Common
Restrictions
on
usage:
None
Author(s):
Manu
Sporny,
Gregg
Kellogg,
Dave
Longley
Change
controller:
W3C
D.
Acknowledgements
The
editors
would
like
to
thank
Mark
Birbeck,
who
provided
a
great
deal
of
the
initial
push
behind
the
JSON-LD
work
via
his
work
on
RDFj,
Dave
Longley,
Dave
Lehn
and
Mike
Johnson
who
reviewed,
provided
feedback,
and
performed
several
implementations
of
the
specification,
and
Ian
Davis,
who
created
RDF/JSON.
Thanks
also
to
Nathan
Rixham,
Bradley
P.
Allen,
Kingsley
Idehen,
Glenn
McDonald,
Alexandre
Passant,
Danny
Ayers,
Ted
Thibodeau
Jr.,
Olivier
Grisel,
Niklas
Lindström,
Markus
Lanthaler,
and
Richard
Cyganiak
for
their
input
on
the
specification.
There
appears
to
have
been
a
problem
fetching
the
style
sheet;
status=0
E.
References
E.1
Normative
references
[BCP47]
A.
Phillips,
M.
Davis.
Tags
for
Identifying
Languages
September
2009.
IETF
Best
Current
Practice.
URL:
http://tools.ietf.org/rfc/bcp/bcp47.txt
[RDF-CONCEPTS]
Graham
Klyne;
Jeremy
J.
Carroll.
Resource
Description
Framework
(RDF):
Concepts
and
Abstract
Syntax.
10
February
2004.
W3C
Recommendation.
URL:
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210
[RFC3987]
M.
Dürst;
M.
Suignard.
Internationalized
Resource
Identifiers
(IRIs).
January
2005.
Internet
RFC
3987.
URL:
http://www.ietf.org/rfc/rfc3987.txt
[RFC4627]
D.
Crockford.
The
application/json
Media
Type
for
JavaScript
Object
Notation
(JSON)
July
2006.
Internet
RFC
4627.
URL:
http://www.ietf.org/rfc/rfc4627.txt
[WEBIDL]
Cameron
McCormack.
Web
IDL.
19
December
2008.
W3C
Working
Draft.
(Work
in
progress.)
URL:
http://www.w3.org/TR/2008/WD-WebIDL-20081219
E.2
Informative
references
[ECMA-262]
ECMAScript
Language
Specification,
Third
Edition.
December
1999.
URL:
http://www.ecma-international.org/publications/standards/Ecma-262.htm
[HTML-RDFA]
Manu
Sporny;
et
al.
HTML+RDFa
04
March
2010.
W3C
Working
Draft.
URL:
http://www.w3.org/TR/rdfa-in-html/
[JSON-LD-API]
Manu
Sporny,
Gregg
Kellogg,
Dave
Longley,
Eds.
JSON-LD
API
Latest.
W3C
Editor's
Draft.
URL:
http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/
[MICRODATA]
Ian
Hickson;
et
al.
Microdata
04
March
2010.
W3C
Working
Draft.
URL:
http://www.w3.org/TR/microdata/
[MICROFORMATS]
Microformats
.
URL:
http://microformats.org
[RDF-PRIMER]
Frank
Manola;
Eric
Miller.
RDF
Primer.
10
February
2004.
W3C
Recommendation.
URL:
http://www.w3.org/TR/2004/REC-rdf-primer-20040210/
[RDF-SCHEMA]
Dan
Brickley;
Ramanathan
V.
Guha.
RDF
Vocabulary
Description
Language
1.0:
RDF
Schema.
10
February
2004.
W3C
Recommendation.
URL:
http://www.w3.org/TR/2004/REC-rdf-schema-20040210
[RDFA-CORE]
Shane
McCarron;
et
al.
RDFa
Core
1.1:
Syntax
and
processing
rules
for
embedding
RDF
through
attributes.
31
March
JSON-LD
Syntax
1.0
.diff
{
font-weight:bold;
color:#0a3;
}
ol.algorithm.update
{
margin-left:
2em;
}
ol.algorithm.update&gt;li
{
list-style-type:
none;
}
ol.algorithm.update&gt;li&gt;span.list-number
{
display:block;
float:
left;
margin-left:
-3.5em;
}
/*****************************************************************
*
ReSpec
CSS
*
Robin
Berjon
(robin
at
berjon
dot
com)
*
v0.05
-
2009-07-31
*****************************************************************/
/*
---
INLINES
---
*/
em.rfc2119
{
text-transform:
lowercase;
font-variant:
small-caps;
font-style:
normal;
color:
#900;
}
h1
acronym,
h2
acronym,
h3
acronym,
h4
acronym,
h5
acronym,
h6
acronym,
a
acronym,
h1
abbr,
h2
abbr,
h3
abbr,
h4
abbr,
h5
abbr,
h6
abbr,
a
abbr
{
border:
none;
}
dfn
{
font-weight:
bold;
}
a.internalDFN
{
color:
inherit;
border-bottom:
1px
solid
#99c;
text-decoration:
none;
}
a.externalDFN
{
color:
inherit;
border-bottom:
1px
dotted
#ccc;
text-decoration:
none;
}
a.bibref
{
text-decoration:
none;
}
code
{
color:
#ff4500;
}
/*
---
WEB
IDL
---
*/
pre.idl
{
border-top:
1px
solid
#90b8de;
border-bottom:
1px
solid
#90b8de;
padding:
1em;
line-height:
120%;
}
pre.idl::before
{
content:
&quot;WebIDL&quot;;
display:
block;
width:
150px;
background:
#90b8de;
color:
#fff;
font-family:
initial;
padding:
3px;
font-weight:
bold;
margin:
-1em
0
1em
-1em;
}
.idlType
{
color:
#ff4500;
font-weight:
bold;
text-decoration:
none;
}
/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID,
.idlDictionaryID
{
font-weight:
bold;
color:
#005a9c;
}
.idlSuperclass
{
font-style:
italic;
color:
#005a9c;
}
/*.idlAttribute*/
.idlAttrType,
.idlFieldType,
.idlMemberType
{
color:
#005a9c;
}
.idlAttrName,
.idlFieldName,
.idlMemberName
{
color:
#ff4500;
}
.idlAttrName
a,
.idlFieldName
a,
.idlMemberName
a
{
color:
#ff4500;
border-bottom:
1px
dotted
#ff4500;
text-decoration:
none;
}
/*.idlMethod*/
.idlMethType
{
color:
#005a9c;
}
.idlMethName
{
color:
#ff4500;
}
.idlMethName
a
{
color:
#ff4500;
border-bottom:
1px
dotted
#ff4500;
text-decoration:
none;
}
/*.idlParam*/
.idlParamType
{
color:
#005a9c;
}
.idlParamName
{
font-style:
italic;
}
.extAttr
{
color:
#666;
}
/*.idlConst*/
.idlConstType
{
color:
#005a9c;
}
.idlConstName
{
color:
#ff4500;
}
.idlConstName
a
{
color:
#ff4500;
border-bottom:
1px
dotted
#ff4500;
text-decoration:
none;
}
/*.idlException*/
.idlExceptionID
{
font-weight:
bold;
color:
#c00;
}
.idlTypedefID,
.idlTypedefType
{
color:
#005a9c;
}
.idlRaises,
.idlRaises
a.idlType,
.idlRaises
a.idlType
code,
.excName
a,
.excName
a
code
{
color:
#c00;
font-weight:
normal;
}
.excName
a
{
font-family:
monospace;
}
.idlRaises
a.idlType,
.excName
a.idlType
{
border-bottom:
1px
dotted
#c00;
}
.excGetSetTrue,
.excGetSetFalse,
.prmNullTrue,
.prmNullFalse,
.prmOptTrue,
.prmOptFalse
{
width:
45px;
text-align:
center;
}
.excGetSetTrue,
.prmNullTrue,
.prmOptTrue
{
color:
#0c0;
}
.excGetSetFalse,
.prmNullFalse,
.prmOptFalse
{
color:
#c00;
}
.idlImplements
a
{
font-weight:
bold;
}
dl.attributes,
dl.methods,
dl.constants,
dl.fields,
dl.dictionary-members
{
margin-left:
2em;
}
.attributes
dt,
.methods
dt,
.constants
dt,
.fields
dt,
.dictionary-members
dt
{
font-weight:
normal;
}
.attributes
dt
code,
.methods
dt
code,
.constants
dt
code,
.fields
dt
code,
.dictionary-members
dt
code
{
font-weight:
bold;
color:
#000;
font-family:
monospace;
}
.attributes
dt
code,
.fields
dt
code,
.dictionary-members
dt
code
{
background:
#ffffd2;
}
.attributes
dt
.idlAttrType
code,
.fields
dt
.idlFieldType
code,
.dictionary-members
dt
.idlMemberType
code
{
color:
#005a9c;
background:
transparent;
font-family:
inherit;
font-weight:
normal;
font-style:
italic;
}
.methods
dt
code
{
background:
#d9e6f8;
}
.constants
dt
code
{
background:
#ddffd2;
}
.attributes
dd,
.methods
dd,
.constants
dd,
.fields
dd,
.dictionary-members
dd
{
margin-bottom:
1em;
}
table.parameters,
table.exceptions
{
border-spacing:
0;
border-collapse:
collapse;
margin:
0.5em
0;
width:
100%;
}
table.parameters
{
border-bottom:
1px
solid
#90b8de;
}
table.exceptions
{
border-bottom:
1px
solid
#deb890;
}
.parameters
th,
.exceptions
th
{
color:
#fff;
padding:
3px
5px;
text-align:
left;
font-family:
initial;
font-weight:
normal;
text-shadow:
#666
1px
1px
0;
}
.parameters
th
{
background:
#90b8de;
}
.exceptions
th
{
background:
#deb890;
}
.parameters
td,
.exceptions
td
{
padding:
3px
10px;
border-top:
1px
solid
#ddd;
vertical-align:
top;
}
.parameters
tr:first-child
td,
.exceptions
tr:first-child
td
{
border-top:
none;
}
.parameters
td.prmName,
.exceptions
td.excName,
.exceptions
td.excCodeName
{
width:
100px;
}
.parameters
td.prmType
{
width:
120px;
}
table.exceptions
table
{
border-spacing:
0;
border-collapse:
collapse;
width:
100%;
}
/*
---
TOC
---
*/
.toc
a
{
text-decoration:
none;
}
a
.secno
{
color:
#000;
}
/*
---
TABLE
---
*/
table.simple
{
border-spacing:
0;
border-collapse:
collapse;
border-bottom:
3px
solid
#005a9c;
}
.simple
th
{
background:
#005a9c;
color:
#fff;
padding:
3px
5px;
text-align:
left;
}
.simple
th[scope=&quot;row&quot;]
{
background:
inherit;
color:
inherit;
border-top:
1px
solid
#ddd;
}
.simple
td
{
padding:
3px
10px;
border-top:
1px
solid
#ddd;
}
.simple
tr:nth-child(even)
{
background:
#f0f6ff;
}
/*
---
DL
---
*/
.section
dd
&gt;
p:first-child
{
margin-top:
0;
}
.section
dd
&gt;
p:last-child
{
margin-bottom:
0;
}
.section
dd
{
margin-bottom:
1em;
}
.section
dl.attrs
dd,
.section
dl.eldef
dd
{
margin-bottom:
0;
}
/*
---
EXAMPLES
---
*/
pre.example
{
border-top:
1px
solid
#ff4500;
border-bottom:
1px
solid
#ff4500;
padding:
1em;
margin-top:
1em;
}
pre.example::before
{
content:
&quot;Example&quot;;
display:
block;
width:
150px;
background:
#ff4500;
color:
#fff;
font-family:
initial;
padding:
3px;
font-weight:
bold;
margin:
-1em
0
1em
-1em;
}
/*
---
EDITORIAL
NOTES
---
*/
.issue
{
padding:
1em;
margin:
1em
0em
0em;
border:
1px
solid
#f00;
background:
#ffc;
}
.issue::before
{
content:
&quot;Issue&quot;;
display:
block;
width:
150px;
margin:
-1.5em
0
0.5em
0;
font-weight:
bold;
border:
1px
solid
#f00;
background:
#fff;
padding:
3px
1em;
}
.note
{
margin:
1em
0em
0em;
padding:
1em;
border:
2px
solid
#cff6d9;
background:
#e2fff0;
}
.note::before
{
content:
&quot;Note&quot;;
display:
block;
width:
150px;
margin:
-1.5em
0
0.5em
0;
font-weight:
bold;
border:
1px
solid
#cff6d9;
background:
#fff;
padding:
3px
1em;
}
/*
---
Best
Practices
---
*/
div.practice
{
border:
solid
#bebebe
1px;
margin:
2em
1em
1em
2em;
}
span.practicelab
{
margin:
1.5em
0.5em
1em
1em;
font-weight:
bold;
font-style:
italic;
}
span.practicelab
{
background:
#dfffff;
}
span.practicelab
{
position:
relative;
padding:
0
0.5em;
top:
-1.5em;
}
p.practicedesc
{
margin:
1.5em
0.5em
1em
1em;
}
@media
screen
{
p.practicedesc
{
position:
relative;
top:
-2em;
padding:
0;
margin:
1.5em
0.5em
-1em
1em;
}
}
/*
---
SYNTAX
HIGHLIGHTING
---
*/
pre.sh_sourceCode
{
background-color:
white;
color:
black;
font-style:
normal;
font-weight:
normal;
}
pre.sh_sourceCode
.sh_keyword
{
color:
#005a9c;
font-weight:
bold;
}
/*
language
keywords
*/
pre.sh_sourceCode
.sh_type
{
color:
#666;
}
/*
basic
types
*/
pre.sh_sourceCode
.sh_usertype
{
color:
teal;
}
/*
user
defined
types
*/
pre.sh_sourceCode
.sh_string
{
color:
red;
font-family:
monospace;
}
/*
strings
and
chars
*/
pre.sh_sourceCode
.sh_regexp
{
color:
orange;
font-family:
monospace;
}
/*
regular
expressions
*/
pre.sh_sourceCode
.sh_specialchar
{
color:
#ffc0cb;
font-family:
monospace;
}
/*
e.g.,
\n,
\t,
\\
*/
pre.sh_sourceCode
.sh_comment
{
color:
#A52A2A;
font-style:
italic;
}
/*
comments
*/
pre.sh_sourceCode
.sh_number
{
color:
purple;
}
/*
literal
numbers
*/
pre.sh_sourceCode
.sh_preproc
{
color:
#00008B;
font-weight:
bold;
}
/*
e.g.,
#include,
import
*/
pre.sh_sourceCode
.sh_symbol
{
color:
blue;
}
/*
e.g.,
*,
+
*/
pre.sh_sourceCode
.sh_function
{
color:
black;
font-weight:
bold;
}
/*
function
calls
and
declarations
*/
pre.sh_sourceCode
.sh_cbracket
{
color:
red;
}
/*
block
brackets
(e.g.,
{,
})
*/
pre.sh_sourceCode
.sh_todo
{
font-weight:
bold;
background-color:
#00FFFF;
}
/*
TODO
and
FIXME
*/
/*
Predefined
variables
and
functions
(for
instance
glsl)
*/
pre.sh_sourceCode
.sh_predef_var
{
color:
#00008B;
}
pre.sh_sourceCode
.sh_predef_func
{
color:
#00008B;
font-weight:
bold;
}
/*
for
OOP
*/
pre.sh_sourceCode
.sh_classname
{
color:
teal;
}
/*
line
numbers
(not
yet
implemented)
*/
pre.sh_sourceCode
.sh_linenum
{
display:
none;
}
/*
Internet
related
*/
pre.sh_sourceCode
.sh_url
{
color:
blue;
text-decoration:
underline;
font-family:
monospace;
}
/*
for
ChangeLog
and
Log
files
*/
pre.sh_sourceCode
.sh_date
{
color:
blue;
font-weight:
bold;
}
pre.sh_sourceCode
.sh_time,
pre.sh_sourceCode
.sh_file
{
color:
#00008B;
font-weight:
bold;
}
pre.sh_sourceCode
.sh_ip,
pre.sh_sourceCode
.sh_name
{
color:
#006400;
}
/*
for
Prolog,
Perl...
*/
pre.sh_sourceCode
.sh_variable
{
color:
#006400;
}
/*
for
LaTeX
*/
pre.sh_sourceCode
.sh_italics
{
color:
#006400;
font-style:
italic;
}
pre.sh_sourceCode
.sh_bold
{
color:
#006400;
font-weight:
bold;
}
pre.sh_sourceCode
.sh_underline
{
color:
#006400;
text-decoration:
underline;
}
pre.sh_sourceCode
.sh_fixed
{
color:
green;
font-family:
monospace;
}
pre.sh_sourceCode
.sh_argument
{
color:
#006400;
}
pre.sh_sourceCode
.sh_optionalargument
{
color:
purple;
}
pre.sh_sourceCode
.sh_math
{
color:
orange;
}
pre.sh_sourceCode
.sh_bibtex
{
color:
blue;
}
/*
for
diffs
*/
pre.sh_sourceCode
.sh_oldfile
{
color:
orange;
}
pre.sh_sourceCode
.sh_newfile
{
color:
#006400;
}
pre.sh_sourceCode
.sh_difflines
{
color:
blue;
}
/*
for
css
*/
pre.sh_sourceCode
.sh_selector
{
color:
purple;
}
pre.sh_sourceCode
.sh_property
{
color:
blue;
}
pre.sh_sourceCode
.sh_value
{
color:
#006400;
font-style:
italic;
}
/*
other
*/
pre.sh_sourceCode
.sh_section
{
color:
black;
font-weight:
bold;
}
pre.sh_sourceCode
.sh_paren
{
color:
red;
}
pre.sh_sourceCode
.sh_attribute
{
color:
#006400;
}
ol.algorithm
{
counter-reset:numsection;
list-style-type:
none;
}
ol.algorithm
li
{
margin:
0.5em
0;
}
ol.algorithm
li:before
{
font-weight:
bold;
counter-increment:
numsection;
content:
counters(numsection,
&quot;.&quot;)
&quot;)
&quot;;
}
JSON-LD
Syntax
1.0
A
Context-based
JSON
Serialization
for
Linking
Data
Unofficial
Draft
24
October
2011
Editor:
Manu
Sporny
,
Digital
Bazaar
Authors:
Manu
Sporny
,
Digital
Bazaar
Dave
Longley
,
Digital
Bazaar
Gregg
Kellogg
,
Kellogg
Associates
Markus
Lanthaler
,
Graz
University
of
Technology
Mark
Birbeck
,
Backplane
Ltd.
This
document
is
also
available
in
this
non-normative
format:
diff
to
previous
version
.
</del>
</abbr>
<del class="diff-old">This
document
is
licensed
under
a
Creative
Commons
Attribution
3.0
License
</del>
</a>.
</p>
<del class="diff-old">Abstract
JSON
[
RFC4627
</del>
<pre class="example">[
<ins class="diff-chg">  {
    "@id": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
    "@type": "http://purl.org/vocab/frbr/core#Work",
    "http://purl.org/dc/terms/title": "Just a Geek",
    "http://purl.org/dc/terms/creator": "Whil Wheaton",
    "http://purl.org/vocab/frbr/core#realization":
      [ "http://purl.oreilly.com/products/9780596007683.BOOK", "http://purl.oreilly.com/products/9780596802189.EBOOK" ]
  },
  {
    "@id": "http://purl.oreilly.com/products/9780596007683.BOOK",
    "@type": "http://purl.org/vocab/frbr/core#Expression",
    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/BOOK"
  },
  {
    "@id": "http://purl.oreilly.com/products/9780596802189.EBOOK",
    "@type": "http://purl.org/vocab/frbr/core#Expression",
    "http://purl.org/dc/terms/type": "http://purl.oreilly.com/product-types/EBOOK"
  }
</ins>
]
<del class="diff-old">has
proven
to
be
a
highly
useful
object
serialization
and
messaging
format.
In
an
attempt
to
harmonize
the
representation
of
Linked
Data
in
JSON,
this
specification
outlines
a
common
JSON
representation
format
for
expressing
directed
graphs;
mixing
both
Linked
Data
and
non-Linked
Data
in
a
single
document.
Status
of
This
Document
This
document
is
merely
a
public
working
draft
of
a
potential
specification.
It
has
no
official
standing
of
any
kind
and
does
not
represent
the
support
or
consensus
of
any
standards
organisation.
This
document
is
an
experimental
work
in
progress.
</del>
</pre>
</div>
<del class="diff-old">Table
of
Contents
1.
Introduction
1.1
How
to
Read
this
Document
1.2
Syntax
Tokens
and
Keywords
1.3
Contributing
2.
Design
2.1
Goals
and
Rationale
2.2
Linked
Data
2.3
Linking
Data
2.4
The
Context
2.4.1
External
Contexts
2.5
From
JSON
to
JSON-LD
3.
Basic
Concepts
3.1
IRIs
3.2
Identifying
the
Subject
3.3
Specifying
the
Type
3.4
Strings
3.5
String
Internationalization
3.6
Typed
Literals
3.7
Multiple
Objects
for
a
Single
Property
3.8
Multiple
Typed
Literals
for
a
Single
Property
3.9
Lists
4.
Advanced
Concepts
4.1
Base
URI
4.2
Default
Vocabulary
4.3
Default
Language
4.4
Vocabulary
Prefixes
4.5
Automatic
Typing
4.6
Type
Coercion
4.7
Chaining
4.8
Identifying
Unlabeled
Nodes
4.9
Aliasing
Keywords
5.
Using
JSON-LD
for
RDF
A.
Markup
Examples
A.1
Turtle
A.1.1
Prefix
and
Base
definitions
A.1.2
Chaining
A.1.3
Lists
A.2
RDFa
A.3
Microformats
A.4
Microdata
B.
Mashing
Up
Vocabularies
C.
IANA
Considerations
D.
Acknowledgements
E.
References
E.1
Normative
references
E.2
Informative
references
</del>
</div>
<div class="appendix section" id="linked-data">
<h2>
<span class="secno">
<del class="diff-old">1.
Introduction
JSON,
as
specified
in
[
RFC4627
],
is
a
simple
language
for
representing
data
on
the
Web.
Linked
Data
is
a
technique
for
creating
a
graph
of
interlinked
data
across
different
documents
or
Web
sites.
Data
entities
are
described
using
IRI
s,
which
are
typically
dereferencable
and
thus
may
be
used
to
find
more
information
about
an
entity,
creating
a
&quot;Web
of
Knowledge&quot;.
JSON-LD
is
intended
to
be
a
simple
publishing
method
for
expressing
not
only
Linked
Data
in
JSON,
but
also
for
adding
semantics
to
existing
JSON.
JSON-LD
is
designed
as
a
light-weight
syntax
that
can
be
used
to
express
Linked
Data
.
It
is
primarily
intended
to
be
a
way
to
use
Linked
Data
in
Javascript
and
other
Web-based
programming
environments.
It
is
also
useful
when
building
interoperable
Web
services
and
when
storing
Linked
Data
in
JSON-based
document
storage
engines.
It
is
practical
and
designed
to
be
as
simple
as
possible,
utilizing
the
large
number
of
JSON
parsers
and
libraries
available
today.
It
is
designed
to
be
able
to
express
key-value
pairs,
RDF
data,
RDFa
[
RDFA-CORE
]
data,
Microformats
[
MICROFORMATS
]
data,
and
Microdata
[
MICRODATA
].
That
is,
it
supports
every
major
Web-based
structured
data
model
in
use
today.
The
syntax
does
not
necessarily
require
applications
to
change
their
JSON,
but
allows
to
easily
add
meaning
by
adding
context
in
a
way
that
is
either
in-band
or
out-of-band.
The
syntax
is
designed
to
not
disturb
already
deployed
systems
running
on
JSON,
but
provide
a
smooth
upgrade
path
from
JSON
to
JSON
with
added
semantics.
Finally,
the
format
is
intended
to
be
easy
to
parse,
efficient
to
generate,
convertible
to
RDF
in
one
pass,
and
require
a
very
small
memory
footprint
in
order
to
operate.
1.1
</del>
<ins class="diff-chg">B.
</ins>
</span>
<del class="diff-old">How
to
Read
this
Document
This
document
is
a
detailed
specification
for
a
serialization
of
</del>
Linked
Data
<del class="diff-old">in
JSON.
The
document
is
primarily
intended
for
the
following
audiences:
Web
developers
that
want
to
understand
the
design
decisions
and
language
syntax
for
JSON-LD.
Software
developers
that
want
to
encode
Microformats,
RDFa,
or
Microdata
in
a
way
that
is
cross-language
compatible
via
JSON.
Software
developers
that
want
to
implement
processors
and
APIs
for
JSON-LD.
This
specification
does
not
describe
the
processing
algorithms
and
programming
interfaces,
for
those
see
[
JSON-LD-API
].
To
understand
the
basics
in
this
specification
you
must
first
be
familiar
with
JSON,
which
is
detailed
in
[
RFC4627
].
To
understand
the
API
and
how
it
is
intended
to
operate
in
a
programming
environment,
it
is
useful
to
have
working
knowledge
of
the
JavaScript
programming
language
[
ECMA-262
]
and
WebIDL
[
WEBIDL
].
To
understand
how
JSON-LD
maps
to
RDF,
it
is
helpful
to
be
familiar
with
the
basic
RDF
concepts
[
RDF-CONCEPTS
].
Examples
may
contain
references
to
existing
vocabularies
and
use
prefix
es
to
refer
to
Web
Vocabularies.
The
following
is
a
list
of
all
vocabularies
and
their
prefix
abbreviations,
as
used
in
this
document:
The
Dublin
Core
vocabulary
(abbreviation:
dc
,
e.g.,
dc:title
)
The
Friend
of
a
Friend
vocabulary
(abbreviation:
foaf
,
e.g.,
foaf:knows
)
The
RDF
vocabulary
(abbreviation:
rdf
,
e.g.,
rdf:type
)
The
XSD
vocabulary
(abbreviation:
xsd
,
e.g.,
xsd:integer
)
JSON
[
RFC4627
]
defines
several
terms
which
are
used
throughout
this
document:
JSON
Object
An
object
structure
is
represented
as
a
pair
of
curly
brackets
surrounding
zero
or
more
name/value
pairs
(or
members).
A
name
is
a
string
.
A
single
colon
comes
after
each
name,
separating
the
name
from
the
value.
A
single
comma
separates
a
value
from
a
following
name.
The
names
within
an
object
should
be
unique.
array
An
array
is
an
ordered
collection
of
values.
An
array
structure
is
represented
as
square
brackets
surrounding
zero
or
more
values
(or
elements).
Elements
are
separated
by
commas.
Within
JSON-LD,
array
order
is
not
preserved
by
default,
unless
specific
markup
is
provided
(see
Lists
).
This
is
because
the
basic
data
model
of
JSON-LD
is
a
linked
data
graph
,
which
is
inherently
unordered.
string
A
string
is
a
sequence
of
zero
or
more
Unicode
characters,
wrapped
in
double
quotes,
using
backslash
escapes.
A
character
is
represented
as
a
single
character
string.
number
A
number
is
is
similar
to
that
used
in
most
programming
languages,
except
that
the
octal
and
hexadecimal
formats
are
not
used
and
that
leading
zeros
are
not
allowed.
true
and
false
Boolean
values.
null
The
use
of
the
null
value
is
undefined
within
JSON-LD.
Supporting
null
in
JSON-LD
might
have
a
number
of
advantages
and
should
be
evaluated.
This
is
currently
an
open
issue
.
1.2
Syntax
Tokens
and
Keywords
JSON-LD
specifies
a
number
of
syntax
tokens
and
keywords
that
are
using
in
all
algorithms
described
in
this
section:
@context
Used
to
set
the
local
context
.
@base
Used
to
set
the
base
IRI
for
all
object
IRIs
affected
by
the
active
context
.
@vocab
Used
to
set
the
base
IRI
for
all
property
IRIs
affected
by
the
active
context
.
@coerce
Used
to
specify
type
coercion
rules.
@literal
Used
to
specify
a
literal
value.
@iri
Used
to
specify
an
IRI
value.
@language
Used
to
specify
the
language
for
a
literal.
@datatype
Used
to
specify
the
datatype
for
a
literal.
:
The
separator
for
JSON
keys
and
values
that
use
the
prefix
mechanism.
@subject
Sets
the
active
subject.
@type
Used
to
set
the
type
of
the
active
subject.
1.3
Contributing
There
are
a
number
of
ways
that
one
may
participate
in
the
development
of
this
specification:
Technical
discussion
typically
occurs
on
the
public
mailing
list:
public-linked-json@w3.org
Public
teleconferences
are
held
on
Tuesdays
at
1500UTC
on
the
second
and
fourth
week
of
each
month.
Specification
bugs
and
issues
should
be
reported
in
the
issue
tracker
.
Source
code
for
the
specification
can
be
found
on
Github.
The
#json-ld
IRC
channel
is
available
for
real-time
discussion
on
irc.freenode.net.
2.
Design
</del>
</h2>
<p>
The
following
<del class="diff-old">section
outlines
the
design
goals
and
rationale
behind
the
JSON-LD
markup
language.
2.1
Goals
and
Rationale
A
number
of
design
considerations
were
explored
during
the
creation
of
this
markup
language:
Simplicity
Developers
need
only
know
JSON
and
three
keywords
to
use
the
basic
functionality
in
JSON-LD.
No
extra
processors
or
software
libraries
are
necessary
to
use
JSON-LD
in
its
most
basic
form.
The
language
attempts
to
ensure
that
developers
have
an
easy
learning
curve.
Compatibility
The
JSON-LD
markup
must
be
100%
compatible
with
JSON.
This
ensures
that
all
of
the
standard
JSON
libraries
work
seamlessly
with
JSON-LD
documents.
Expressiveness
The
syntax
must
be
able
to
express
directed
graphs,
which
have
been
proven
to
be
able
to
simply
express
almost
every
real
world
data
model.
Terseness
The
JSON-LD
syntax
must
be
very
terse
and
human
readable,
requiring
as
little
as
possible
effort
from
the
developer.
Zero
Edits,
most
of
the
time
JSON-LD
provides
a
mechanism
that
allows
developers
to
specify
context
in
a
way
that
is
out-of-band.
This
allows
organizations
that
have
already
deployed
large
JSON-based
infrastructure
to
add
meaning
to
their
JSON
documents
in
a
way
that
is
not
disruptive
to
their
day-to-day
operations
and
is
transparent
to
their
current
customers.
At
times,
mapping
JSON
to
a
graph
representation
can
become
difficult.
In
these
instances,
rather
than
having
JSON-LD
support
esoteric
markup,
we
chose
not
to
support
the
use
case
and
support
a
simplified
syntax
instead.
So,
while
Zero
Edits
is
a
goal,
it
is
not
always
possible
without
adding
great
complexity
to
the
language.
One-pass
Processing
JSON-LD
supports
one-pass
processing,
which
results
in
a
very
small
memory
footprint
when
processing
documents.
For
example,
to
convert
a
JSON-LD
document
into
an
RDF
document
of
any
kind,
only
one
pass
is
required
over
the
data.
2.2
Linked
Data
The
following
</del>
definition
for
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
is
the
one
that
will
be
used
for
this
specification.
</p>
<ol>
<li>
<dfn title="linked_data" id="dfn-linked_data">
Linked
Data
</dfn>
is
a
set
of
documents,
each
containing
a
representation
of
a
linked
data
graph.
</li>
<li>
A
<dfn title="linked_data_graph" id="dfn-linked_data_graph">
linked
data
graph
</dfn>
is
an
unordered
labeled
directed
graph,
where
nodes
are
<a class="tref internalDFN" title="subject" href="#dfn-subject">
subject
</a>
s
or
<a class="tref internalDFN" title="object" href="#dfn-object">
object
</a>
s,
and
edges
are
properties.
</li>
<li>
A
<dfn title="subject" id="dfn-subject">
subject
</dfn>
is
any
node
in
a
<a class="tref internalDFN" title="linked_data_graph" href="#dfn-linked_data_graph">
linked
data
graph
</a>
with
at
least
one
outgoing
edge.
</li>
<li>
A
<a class="tref internalDFN" title="subject" href="#dfn-subject">
subject
</a>
<em class="rfc2119" title="should">
should
</em>
be
labeled
with
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
(an
Internationalized
Resource
Identifier
as
described
in
[
<cite>
<a class="bibref" rel="biblioentry" href="#bib-RFC3987">
RFC3987
</a>
</cite>
]).
</li>
<li>
An
<dfn title="object" id="dfn-object">
object
</dfn>
is
a
node
in
a
<a class="tref internalDFN" title="linked_data_graph" href="#dfn-linked_data_graph">
linked
data
graph
</a>
with
at
least
one
incoming
edge.
</li>
<li>
An
<a class="tref internalDFN" title="object" href="#dfn-object">
object
</a>
<em class="rfc2119" title="may">
may
</em>
be
labeled
with
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>.
</li>
<li>
An
object
<em class="rfc2119" title="may">
may
</em>
be
a
<a class="tref internalDFN" title="subject" href="#dfn-subject">
subject
</a>
and
<a class="tref internalDFN" title="object" href="#dfn-object">
object
</a>
at
the
same
time.
</li>
<li>
A
<dfn title="property" id="dfn-property">
property
</dfn>
is
an
edge
of
the
<a class="tref internalDFN" title="linked_data_graph" href="#dfn-linked_data_graph">
linked
data
graph
</a>.
</li>
<li>
A
<a class="tref internalDFN" title="property" href="#dfn-property">
property
</a>
<em class="rfc2119" title="should">
should
</em>
be
labeled
with
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>.
</li>
<li>
An
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
that
is
a
label
in
a
<a class="tref internalDFN" title="linked_data_graph" href="#dfn-linked_data_graph">
linked
data
graph
</a>
<em class="rfc2119" title="should">
should
</em>
be
dereferencable
to
a
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
document
describing
the
labeled
<a class="tref internalDFN" title="subject" href="#dfn-subject">
subject
</a>,
<a class="tref internalDFN" title="object" href="#dfn-object">
object
</a>
or
<a class="tref internalDFN" title="property" href="#dfn-property">
property
</a>.
</li>
<li>
A
<dfn title="literal" id="dfn-literal">
literal
</dfn>
is
an
<a class="tref internalDFN" title="object" href="#dfn-object">
object
</a>
with
a
label
that
is
not
an
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>
</li>
</ol>
<p>
Note
that
the
definition
for
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>
above
is
silent
on
the
topic
of
unlabeled
nodes.
Unlabeled
nodes
are
not
considered
<a class="tref internalDFN" title="linked_data" href="#dfn-linked_data">
Linked
Data
</a>.
However,
this
specification
allows
for
the
expression
of
unlabled
nodes,
as
most
graph-based
data
sets
on
the
Web
contain
a
number
of
associated
nodes
that
are
not
named
and
thus
are
not
directly
de-referenceable.
</p>
</div>
<del class="diff-old">2.3
Linking
Data
An
Internationalized
Resource
Identifier
(
IRI
),
as
described
in
[
RFC3987
],
is
a
mechanism
for
representing
unique
identifiers
on
the
web.
In
Linked
Data
,
an
IRI
is
commonly
used
for
expressing
a
subject
,
a
property
or
an
object
.
JSON-LD
defines
a
mechanism
to
map
JSON
terms,
i.e.,
keys
and
values,
to
IRIs.
This
does
not
mean
that
JSON-LD
requires
every
key
or
value
to
be
an
IRI,
but
rather
ensures
that
keys
and
values
can
be
mapped
to
IRIs
if
the
developer
desires
to
transform
their
data
into
Linked
Data
.
There
are
a
few
techniques
that
can
ensure
that
developers
will
generate
good
Linked
Data
for
the
Web.
JSON-LD
formalizes
those
techniques.
We
will
be
using
the
following
JSON
markup
as
the
example
for
the
rest
of
this
section:
  {
    &quot;name&quot;: &quot;Manu Sporny&quot;,
    &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
2.4
The
Context
In
JSON-LD,
a
context
is
used
to
map
term
s,
i.e.,
keys
and
values
in
an
JSON
document,
to
IRI
s.
A
term
is
a
short
word
that
may
be
expanded
to
an
IRI
.
The
Web
uses
IRIs
for
unambiguous
identification.
The
idea
is
that
these
term
s
mean
something
that
may
be
of
use
to
other
developers
and
that
it
is
useful
to
give
them
an
unambiguous
identifier.
That
is,
it
is
useful
for
term
s
to
expand
to
IRIs
so
that
developers
don't
accidentally
step
on
each
other's
Web
Vocabulary
terms.
For
example,
the
term
name
may
map
directly
to
the
IRI
http://xmlns.com/foaf/0.1/name
.
This
allows
JSON-LD
documents
to
be
constructed
using
the
common
JSON
practice
of
simple
name/value
pairs
while
ensuring
that
the
data
is
useful
outside
of
the
page,
API
or
database
in
which
it
resides.
These
Linked
Data
term
s
are
typically
collected
in
a
context
document
that
would
look
something
like
this:
  {
    &quot;@context&quot;: {
      &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
      &quot;homepage&quot;: &quot;http://xmlns.com/foaf/0.1/homepage&quot;,
      &quot;avatar&quot;: &quot;http://xmlns.com/foaf/0.1/avatar&quot;
    }
}
This
context
document
can
then
be
used
in
an
JSON-LD
document
by
adding
a
single
line.
The
JSON
markup
as
shown
in
the
previous
section
could
be
changed
as
follows
to
link
to
the
context
document:
  {
    
    &quot;name&quot;: &quot;Manu Sporny&quot;,
    &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
The
additions
above
transform
the
previous
JSON
document
into
a
JSON
document
with
added
semantics
because
the
@context
specifies
how
the
name
,
homepage
,
and
avatar
terms
map
to
IRIs.
Mapping
those
keys
to
IRIs
gives
the
data
global
context.
If
two
developers
use
the
same
IRI
to
describe
a
property,
they
are
more
than
likely
expressing
the
same
concept.
This
allows
both
developers
to
re-use
each
others
data
without
having
to
agree
to
how
their
data
will
inter-operate
on
a
site-by-site
basis.
Contexts
may
also
contain
datatype
information
for
certain
term
s
as
well
as
other
processing
instructions
for
the
JSON-LD
processor.
Contexts
may
be
specified
in-line.
This
ensures
that
JSON-LD
documents
can
be
processed
when
a
JSON-LD
processor
does
not
have
access
to
the
Web.
  {
    &quot;@context&quot;: {
      &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
      &quot;homepage&quot;: &quot;http://xmlns.com/foaf/0.1/homepage&quot;,
      &quot;avatar&quot;: &quot;http://xmlns.com/foaf/0.1/avatar&quot;
    },
    &quot;name&quot;: &quot;Manu Sporny&quot;,
    &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
Contexts
may
be
used
at
any
time
a
JSON
object
is
defined,
and
a
JSON
object
may
specify
multiple
contexts,
to
be
processed
in
order,
for
example
to
include
standard
prefix
definitions
along
with
a
local
language
definition
used
to
set
the
language
of
plain
literal
s:
The
set
of
contexts
defined
within
a
specific
JSON
Object
is
termed
a
local
context
.
The
active
context
refers
to
the
accumulation
of
local
context
s
that
are
in
scope
at
a
specific
point
within
the
document.
  {
    &quot;@context&quot;: [
      &quot;http://example.org/json-ld-contexts/person&quot;,
      {
        &quot;@language&quot;: &quot;en&quot;
      }
    ],
    &quot;name&quot;: &quot;Manu Sporny&quot;,
    &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
JSON-LD
strives
to
ensure
that
developers
don't
have
to
change
the
JSON
that
is
going
into
and
being
returned
from
their
Web
APIs.
This
means
that
developers
can
also
specify
a
context
for
JSON
data
in
an
out-of-band
fashion.
This
is
described
later
in
this
document.
JSON-LD
uses
a
special
type
of
machine-readable
document
called
a
Web
Vocabulary
to
define
term
s
that
are
then
used
to
describe
concepts
and
&quot;things&quot;
in
the
world.
Typically,
these
Web
Vocabulary
documents
have
prefix
es
associated
with
them
and
contain
a
number
of
term
declarations.
Prefix
es
are
helpful
when
a
developer
wants
to
mix
multiple
vocabularies
together
in
a
context
,
but
does
not
want
to
go
to
the
trouble
of
defining
every
single
term
in
every
single
vocabulary.
Some
Web
Vocabularies
may
have
dozens
of
terms
defined.
If
a
developer
wants
to
use
3-4
different
vocabularies,
the
number
of
terms
that
would
have
to
be
declared
in
a
single
context
could
become
quite
large.
To
reduce
the
number
of
different
terms
that
must
be
defined,
JSON-LD
also
allows
prefixes
to
be
used
to
compact
IRIs.
For
example,
the
IRI
http://xmlns.com/foaf/0.1/
specifies
a
Web
Vocabulary
which
may
be
represented
using
the
foaf
prefix
.
The
foaf
Web
Vocabulary
contains
a
term
called
name
.
If
you
join
the
foaf
prefix
with
the
name
suffix,
you
can
build
a
compact
IRI
that
will
expand
out
into
an
absolute
IRI
for
the
http://xmlns.com/foaf/0.1/name
vocabulary
term.
That
is,
the
compact
IRI,
or
short-form,
is
foaf:name
and
the
expanded-form
is
http://xmlns.com/foaf/0.1/name
.
This
vocabulary
term
is
used
to
specify
a
person's
name.
Developers,
and
machines,
are
able
to
use
this
IRI
(plugging
it
directly
into
a
web
browser,
for
instance)
to
go
to
the
term
and
get
a
definition
of
what
the
term
means.
Much
like
we
can
use
WordNet
today
to
see
the
definition
of
words
in
the
English
language.
Developers
and
machines
need
the
same
sort
of
definition
of
terms.
IRIs
provide
a
way
to
ensure
that
these
terms
are
unambiguous.
The
context
provides
a
collection
of
vocabulary
term
s
and
prefix
es
that
can
be
used
to
expand
JSON
keys
and
values
into
IRI
s.
To
ensure
the
best
possible
performance,
it
is
a
best
practice
to
put
the
context
definition
at
the
top
of
the
JSON-LD
document.
If
it
isn't
listed
first,
processors
have
to
save
each
key-value
pair
until
the
context
is
processed.
This
creates
a
memory
and
complexity
burden
for
one-pass
processors.
2.4.1
External
Contexts
Authors
may
choose
to
declare
JSON-LD
context
s
in
external
documents
to
promote
re-use
of
contexts
as
well
as
reduce
the
size
of
JSON-LD
documents.
In
order
to
use
an
external
context,
an
author
may
specify
an
IRI
to
a
valid
JSON-LD
document.
The
referenced
document
must
have
a
top-level
JSON
Object
.
The
value
of
any
@context
key
within
that
object
is
substituted
for
the
IRI
within
the
referencing
document
to
have
the
same
effect
as
if
the
value
were
specified
inline
within
the
referencing
document.
The
following
example
demonstrates
the
use
of
an
external
context:
  {
    ,
    &quot;name&quot;: &quot;Manu Sporny&quot;,
    &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
Authors
may
also
import
multiple
contexts
or
a
combination
of
external
and
local
contexts
by
specifying
a
list
of
contexts:
  {
    
    &quot;name&quot;: &quot;Manu Sporny&quot;,
    &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
    &quot;celebrates&quot;:
    {
       &quot;@type&quot;: &quot;Event&quot;,
       &quot;description&quot;: &quot;International Talk Like a Pirate Day&quot;,
       &quot;date&quot;: &quot;R/2011-09-19&quot;
    }
}
Each
context
in
a
list
will
be
evaluated
in-order.
Duplicate
mappings
within
the
context
s
must
be
overwritten
on
a
last-defined-overrides
basis.
The
context
list
must
contain
either
de-referenceable
IRI
s
or
JSON
Object
s
that
conform
to
the
context
syntax
as
described
in
this
document.
External
JSON-LD
context
documents
may
contain
extra
information
located
outside
of
the
@context
key,
such
as
documentation
about
the
prefix
es
declared
in
the
document.
It
is
also
recommended
that
a
human-readable
document
encoded
in
HTML+RDFa
[
HTML-RDFA
]
or
other
Linked
Data
compatible
format
is
served
as
well
to
explain
the
correct
usage
of
the
JSON-LD
context
document.
2.5
From
JSON
to
JSON-LD
If
a
set
of
terms
such
as,
name
,
homepage
,
and
avatar
,
are
defined
in
a
context
,
and
that
context
is
used
to
resolve
the
names
in
JSON
objects,
machines
are
able
to
automatically
expand
the
terms
to
something
meaningful
and
unambiguous,
like
this:
  {
    &quot;&quot;: &quot;Manu Sporny&quot;,
    &quot;&quot;: &quot;http://manu.sporny.org&quot;
    &quot;&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
Doing
this
allows
JSON
to
be
unambiguously
machine-readable
without
requiring
developers
to
drastically
change
their
workflow.
Please
note
that
this
JSON-LD
document
doesn't
define
the
subject
and
will
thus
result
in
an
unlabeled
or
blank
node.
3.
Basic
Concepts
JSON-LD
is
designed
to
ensure
that
Linked
Data
concepts
can
be
marked
up
in
a
way
that
is
simple
to
understand
and
author
by
Web
developers.
In
many
cases,
regular
JSON
markup
can
become
Linked
Data
with
the
simple
addition
of
a
context
.
As
more
JSON-LD
features
are
used,
more
semantics
are
added
to
the
JSON
markup.
3.1
IRIs
Expressing
IRI
s
are
fundamental
to
Linked
Data
as
that
is
how
most
subject
s
and
many
object
are
named.
IRI
s
can
be
expressed
in
a
variety
of
different
ways
in
JSON-LD.
In
general,
term
s
in
the
key
position
in
a
JSON
object
that
have
a
mapping
to
an
IRI
or
another
key
in
the
context
are
expanded
to
an
IRI
by
JSON-LD
processors.
There
are
special
rules
for
processing
keys
in
@context
and
when
dealing
with
keys
that
start
with
the
@subject
character.
An
IRI
is
generated
for
the
value
specified
using
@subject
,
if
it
is
a
string
.
An
IRI
is
generated
for
the
value
specified
using
@type
.
An
IRI
is
generated
for
the
value
specified
using
the
@iri
keyword.
An
IRI
is
generated
when
there
are
@coerce
rules
in
effect
for
a
key
named
@iri
.
IRIs
can
be
expressed
directly
in
the
key
position
like
so:
  {
  ...
    &quot;&quot;: &quot;Manu Sporny&quot;,
  ...
}
In
the
example
above,
the
key
http://xmlns.com/foaf/0.1/name
is
interpreted
as
an
IRI
,
as
opposed
to
being
interpreted
as
a
string.
Term
expansion
occurs
for
IRIs
if
a
term
is
defined
within
the
active
context
:
  {
    &quot;&quot;},
  ...
    &quot;&quot;: &quot;Manu Sporny&quot;,
  ...
}
Prefix
es
are
expanded
when
used
in
keys:
  {
    &quot;&quot;},
  ...
    &quot;&quot;: &quot;Manu Sporny&quot;,
  ...
}
foaf:name
above
will
automatically
expand
out
to
the
IRI
http://xmlns.com/foaf/0.1/name
.
An
IRI
is
generated
when
a
value
is
associated
with
a
key
using
the
@iri
keyword:
  {
  ...
    &quot;homepage&quot;: { &quot;&quot;: &quot;http://manu.sporny.org&quot; }
  ...
}
If
type
coercion
rules
are
specified
in
the
@context
for
a
particular
vocabulary
term,
an
IRI
is
generated:
  
    &quot;@context&quot;:
    {
      ...
      &quot;@coerce&quot;:
      {
        &quot;@iri&quot;: &quot;homepage&quot;
      }
    }
  ...
    &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
  ...
}
Even
though
the
value
http://manu.sporny.org/
is
a
string
,
the
type
coercion
rules
will
transform
the
value
into
an
IRI
when
processed
by
a
JSON-LD
Processor
IRIs
may
be
represented
as
an
absolute
IRI,
a
term
,
a
prefix
:
term
construct,
or
as
a
value
relative
to
@base
or
@vocab
.
3.2
Identifying
the
Subject
To
be
able
to
externally
reference
nodes,
it
is
important
that
each
node
has
an
unambiguous
identifier.
IRI
s
are
a
fundamental
concept
of
Linked
Data
,
and
nodes
should
have
a
de-referencable
identifier
used
to
name
and
locate
them.
For
nodes
to
be
truely
linked,
de-referencing
the
identifier
should
result
in
a
representation
of
that
node.
Associating
an
IRI
with
a
node
tells
an
application
that
the
returned
document
contains
a
description
of
the
node
requested.
JSON-LD
documents
may
also
contain
descriptions
of
other
nodes,
so
it
is
necessary
to
be
able
to
uniquely
identify
each
node
which
may
be
externally
referenced.
A
subject
of
an
object
in
JSON
is
declared
using
the
@subject
key.
The
subject
is
the
first
piece
of
information
needed
by
the
JSON-LD
processor
in
order
to
create
the
(subject,
property,
object)
tuple,
also
known
as
a
triple.
  {
  ...
    &quot;&quot;,
  ...
}
The
example
above
would
set
the
subject
to
the
IRI
http://example.org/people#joebob
.
To
ensure
the
best
possible
performance,
it
is
a
best
practice
to
put
the
@subject
key
before
other
key-value
pairs
in
an
object.
If
it
isn't
listed
first,
processors
have
to
save
each
key-value
pair
until
@subject
is
processed
before
they
can
create
valid
triples.
This
creates
a
memory
and
complexity
burden
for
one-pass
processors.
3.3
Specifying
the
Type
The
type
of
a
particular
subject
can
be
specified
using
the
@type
key.
Specifying
the
type
in
this
way
will
generate
a
triple
of
the
form
(subject,
type,
type-iri).
To
be
Linked
Data
,
types
must
be
uniquely
identified
by
an
IRI
.
  {
  ...
    &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
    &quot;&quot;,
  ...
}
The
example
above
would
generate
the
following
triple
if
the
JSON-LD
document
is
mapped
to
RDF
(in
N-Triples
notation):
  &lt;http://example.org/people#joebob&gt;
     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt;
&lt;http://xmlns.com/foaf/0.1/Person&gt;
.
3.4
Strings
Regular
text
strings,
also
referred
to
as
plain
literal
s,
are
easily
expressed
using
regular
JSON
string
s.
  {
  ...
    &quot;name&quot;: &quot;&quot;,
  ...
}
3.5
String
Internationalization
JSON-LD
makes
an
assumption
that
strings
with
associated
language
encoding
information
are
not
very
common
when
used
in
JavaScript
and
Web
Services.
Thus,
it
takes
a
little
more
effort
to
express
strings
with
associated
language
information.
  {
  ...
    &quot;name&quot;: 
    {
      &quot;@literal&quot;: &quot;花澄&quot;,
      &quot;@language&quot;: &quot;ja&quot;
    }
  ...
}
The
example
above
would
generate
a
plain
literal
for
花澄
and
associate
the
ja
language
code
with
the
triple
that
is
generated.
Languages
must
be
expressed
in
[
BCP47
]
format.
It
is
also
possible
to
set
a
language
to
use
within
a
@context
,
to
allow
specify
a
language
to
apply
to
all
plain
literal
s
within
the
scope
of
the
context
  {
    &quot;@context:&quot; {
      &quot;@language&quot;: &quot;ja&quot;
    },
  ...
    &quot;name&quot;: 
  ...
}
3.6
Typed
Literals
A
value
with
an
associated
datatype,
also
known
as
a
typed
literal
,
is
indicated
by
associating
a
literal
with
an
IRI
which
indicates
the
literal's
datatype.
Typed
literals
may
be
expressed
in
JSON-LD
in
three
ways:
By
utilizing
the
@coerce
keyword.
By
utilizing
the
expanded
form
for
specifying
objects.
By
using
a
native
JSON
datatype.
The
first
example
uses
the
@coerce
keyword
to
express
a
typed
literal:
  
    &quot;@context&quot;:
    {
      &quot;modified&quot;:  &quot;http://purl.org/dc/terms/modified&quot;,
      &quot;dateTime&quot;: &quot;http://www.w3.org/2001/XMLSchema#dateTime&quot;
      &quot;@coerce&quot;:
      {
        &quot;dateTime&quot;: &quot;modified&quot;
      }
    }
  ...
    &quot;modified&quot;: &quot;2010-05-29T14:17:39+02:00&quot;,
  ...
}
The
second
example
uses
the
expanded
form
for
specifying
objects:
  {
  ...
    &quot;modified&quot;: 
    {
      &quot;@literal&quot;: &quot;2010-05-29T14:17:39+02:00&quot;,
      &quot;@datatype&quot;: &quot;dateTime&quot;
    }
  ...
}
Both
examples
above
would
generate
an
object
with
the
literal
value
of
2010-05-29T14:17:39+02:00
and
the
datatype
of
http://www.w3.org/2001/XMLSchema#dateTime
.
The
third
example
uses
a
built-in
native
JSON
type,
a
number
,
to
express
a
datatype:
  {
  ...
    &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
    &quot;age&quot;: 
  ...
}
The
example
above
would
generate
the
following
triple:
  &lt;http://example.org/people#joebob&gt;
     &lt;http://xmlns.com/foaf/0.1/age&gt;
&quot;31&quot;^^&lt;http://www.w3.org/2001/XMLSchema#integer&gt;
.
3.7
Multiple
Objects
for
a
Single
Property
A
JSON-LD
author
can
express
multiple
triples
in
a
compact
way
by
using
array
s.
If
a
subject
has
multiple
values
for
the
same
property,
the
author
may
express
each
property
as
an
array
.
In
JSON-LD,
multiple
objects
on
a
property
are
not
ordered.
This
is
because
typically
graphs
are
not
inherently
ordered
data
structures.
To
see
more
on
creating
ordered
collections
in
JSON-LD,
see
Lists
.
  {
  ...
    &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
    &quot;nick&quot;: ,
  ...
}
The
markup
shown
above
would
generate
the
following
triples:
  &lt;http://example.org/people#joebob&gt;
     &lt;http://xmlns.com/foaf/0.1/nick&gt;
        &quot;joe&quot; .
  &lt;http://example.org/people#joebob&gt;
     &lt;http://xmlns.com/foaf/0.1/nick&gt;
        &quot;bob&quot; .
  &lt;http://example.org/people#joebob&gt;
     &lt;http://xmlns.com/foaf/0.1/nick&gt;
&quot;jaybee&quot;
.
3.8
Multiple
Typed
Literals
for
a
Single
Property
Multiple
typed
literal
s
may
also
be
expressed
using
the
expanded
form
for
objects:
  {
  ...
    &quot;@subject&quot;: &quot;http://example.org/articles/8&quot;,
    &quot;modified&quot;: 
    [
      {
        &quot;@literal&quot;: &quot;2010-05-29T14:17:39+02:00&quot;,
        &quot;@datatype&quot;: &quot;dateTime&quot;
      },
      {
        &quot;@literal&quot;: &quot;2010-05-30T09:21:28-04:00&quot;,
        &quot;@datatype&quot;: &quot;dateTime&quot;
      }
    ]
  ...
}
The
markup
shown
above
would
generate
the
following
triples:
  &lt;http://example.org/articles/8&gt;
     &lt;http://purl.org/dc/terms/modified&gt;
        &quot;2010-05-29T14:17:39+02:00&quot;^^http://www.w3.org/2001/XMLSchema#dateTime .
  &lt;http://example.org/articles/8&gt;
     &lt;http://purl.org/dc/terms/modified&gt;
&quot;2010-05-30T09:21:28-04:00&quot;^^http://www.w3.org/2001/XMLSchema#dateTime
.
3.9
Lists
Because
graphs
do
not
describe
ordering
for
links
between
nodes,
in
contrast
to
plain
JSON,
multi-valued
properties
in
JSON-LD
do
not
provide
an
ordering
of
the
listed
objects.
For
example,
consider
the
following
simple
document:
    {
  ...
    &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
    &quot;nick&quot;: ,
  ...
}
This
results
in
three
triples
being
generated,
each
relating
the
subject
to
an
individual
object,
with
no
inherent
order.
To
preserve
the
order
of
the
objects,
RDF-based
languages,
such
as
[
TURTLE
]
use
the
concept
of
an
rdf:List
(as
described
in
[
RDF-SCHEMA
]).
This
uses
a
sequence
of
unlabeled
nodes
with
properties
describing
a
value,
a
null-terminated
next
property.
Without
specific
syntactical
support,
this
could
be
represented
in
JSON-LD
as
follows:
    {
  ...
    &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
    &quot;nick&quot;: ,
      ,
      
        ,
        
          ,
          
          
        
      
    ,
  ...
}
As
this
notation
is
rather
unwieldy
and
the
notion
of
ordered
collections
is
rather
important
in
data
modeling,
it
is
useful
to
have
specific
language
support.
In
JSON-LD,
a
list
may
be
represented
using
the
@list
keyword
as
follows:
    {
  ...
    &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
    &quot;foaf:nick&quot;: ,
  ...
}
This
describes
the
use
of
this
array
as
being
ordered,
and
order
is
maintained
through
normalization
and
RDF
conversion
as
described
in
[
JSON-LD-API
].
If
every
use
of
a
given
multi-valued
property
is
a
list,
this
may
be
abbreviated
by
adding
an
@coerce
term:
    {
    
      ...
      
        
      
    ,
  ...
    &quot;@subject&quot;: &quot;http://example.org/people#joebob&quot;,
    &quot;foaf:nick&quot;: ,
  ...
}
The
@list
keyword
can
be
used
within
the
@coerce
section
of
a
@context
to
cause
value
arrays
to
be
coerced
into
an
ordered
list.
4.
Advanced
Concepts
JSON-LD
has
a
number
of
features
that
provide
functionality
above
and
beyond
the
core
functionality
described
above.
The
following
sections
outline
the
features
that
are
specific
to
JSON-LD.
4.1
Base
URI
JSON-LD
allows
IRI
s
to
be
specified
in
a
relative
form.
For
subject
and
object
IRIs,
relative
IRIs
are
resolved
against
the
document
base
using
section
5.1
Establishing
a
Base
URI
of
[
RFC3986
].
This
value
may
be
explicitly
set
with
a
context
using
the
@base
keyword.
For
example,
if
a
JSON-LD
document
was
retrieved
from
http://manu.sporny.org/
,
relative
IRIs
would
resolve
against
that
URI:
  {
    ,
    &quot;http://xmlns.com/foaf/0.1/name&quot;: &quot;Manu Sporny&quot;,
    &quot;http://xmlns.com/foaf/0.1/homepage: &quot;&quot;
}
This
document
uses
an
empty
@subject
,
which
resolves
to
the
document
base.
However,
if
the
document
is
moved
to
a
different
location,
the
subject
IRI
would
change.
To
prevent
this,
a
context
may
have
a
@base
mapping,
to
set
an
absolute
base
for
the
document
in
spite
of
where
it
actually
is
retrieved
from.
It
must
have
a
value
of
a
simple
string
with
the
lexical
form
of
an
absolute
IRI
.
  {
    ,
    &quot;@subject&quot;: &quot;about/&quot;,
    &quot;http://xmlns.com/foaf/0.1/name&quot;: &quot;Manu Sporny&quot;,
    &quot;http://xmlns.com/foaf/0.1/homepage: &quot;&quot;
}
4.2
Default
Vocabulary
It
is
often
common
that
all
types
and
properties
come
from
the
same
vocabulary.
JSON-LD
provides
a
way
to
set
a
base
URI
to
be
used
for
all
properties
and
types
that
aren't
based
on
terms,
prefixes
or
absolute
IRIs.
Much
like
the
@base
keyword,
the
@vocab
keyword
can
be
used
to
set
a
base
IRI
to
use
for
all
types
and
properties
that
don't
otherwise
resolve
to
an
absolute
IRI
.
  {
    
    ,
    &quot;name&quot;: &quot;Manu Sporny&quot;,
    &quot;homepage&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
}
4.3
Default
Language
JSON-LD
allows
a
default
value
to
use
as
the
language
for
plain
literal
s.
It
is
commonly
the
case
that
documents
are
written
using
a
single
language.
As
described
in
String
Internationalization
,
a
language-tagged
literal
may
be
specified
as
follows:
  {
  ...
    &quot;name&quot;:
    {
      &quot;@literal&quot;: &quot;花澄&quot;,
      &quot;@language&quot;: &quot;ja&quot;
    }
  ...
}
By
specifying
@language
within
a
context
,
multiple
language-tagged
literals
may
be
marked
up
using
a
simple
string
form:
  {
    ,
  ...
    &quot;name&quot;: 
  ...
}
4.4
Vocabulary
Prefixes
Vocabulary
terms
in
Linked
Data
documents
may
draw
from
a
number
of
different
Web
vocabularies.
At
times,
declaring
every
single
term
that
a
document
uses
can
require
the
developer
to
declare
tens,
if
not
hundreds
of
potential
vocabulary
terms
that
may
be
used
across
an
application.
This
is
a
concern
for
at
least
three
reasons;
the
first
is
the
cognitive
load
on
the
developer,
the
second
is
the
serialized
size
of
the
context
,
the
third
is
future-proofing
application
contexts.
In
order
to
address
these
issues,
the
concept
of
a
prefix
mechanism
is
introduced.
A
prefix
is
a
compact
way
of
expressing
a
base
IRI
to
a
Web
Vocabulary
.
Generally,
these
prefixes
are
used
by
concatenating
the
prefix
and
a
suffix
separated
by
a
colon
(
:
).
The
prefix
is
a
term
taken
from
the
active
context
,
a
short
string
that
identifies
a
particular
Web
vocabulary.
For
example,
the
prefix
foaf
may
be
used
as
a
short
hand
for
the
Friend-of-a-Friend
Web
Vocabulary,
which
is
identified
using
the
IRI
http://xmlns.com/foaf/0.1/
.
A
developer
may
append
any
of
the
FOAF
Vocabulary
terms
to
the
end
of
the
prefix
to
specify
a
short-hand
version
of
the
absolute
IRI
for
the
vocabulary
term.
For
example,
foaf:name
would
be
expanded
out
to
the
IRI
http://xmlns.com/foaf/0.1/name
.
Instead
of
having
to
remember
and
type
out
the
entire
IRI,
the
developer
can
instead
use
the
prefix
in
their
JSON-LD
markup.
The
ability
to
use
prefix
es
reduces
the
need
for
developers
to
declare
every
vocabulary
term
that
they
intend
to
use
in
the
JSON-LD
context
.
This
reduces
document
serialization
size
because
every
vocabulary
term
need
not
be
declared
in
the
context.
Prefix
also
reduce
the
cognitive
load
on
the
developer.
It
is
far
easier
to
remember
foaf:name
than
it
is
to
remember
http://xmlns.com/foaf/0.1/name
.
The
use
of
prefixes
also
ensures
that
a
context
document
does
not
have
to
be
updated
in
lock-step
with
an
externally
defined
Web
Vocabulary
.
Without
prefixes,
a
developer
would
need
to
keep
their
application
context
terms
in
lock-step
with
an
externally
defined
Web
Vocabulary.
Rather,
by
just
declaring
the
Web
Vocabulary
prefix,
one
can
use
new
terms
as
they're
declared
without
having
to
update
the
application's
JSON-LD
context
.
Consider
the
following
example:
    {
    &quot;@context&quot;: {
      
      
    },
    &quot;@subject&quot;: &quot;http://example.org/library&quot;,
    &quot;@type&quot;: ,
    : {
      &quot;@subject&quot;: &quot;http://example.org/library/the-republic&quot;,
      &quot;@type&quot;: ,
      : &quot;Plato&quot;,
      : &quot;The Republic&quot;,
      : {
        &quot;@subject&quot;: &quot;http://example.org/library/the-republic#introduction&quot;,
        &quot;@type&quot;: ,
        : &quot;An introductory chapter on The Republic.&quot;,
        : &quot;The Introduction&quot;
      },
    },
}
In
this
example,
two
different
vocabularies
are
referred
to
using
prefixes.
Those
prefixes
are
then
used
as
type
and
property
values
using
the
prefix:suffix
notation.
Prefixes,
also
known
as
CURIEs,
are
defined
more
formally
in
RDFa
Core
1.1,
Section
6
&quot;CURIE
Syntax
Definition&quot;
[
RDFA-CORE
].
JSON-LD
does
not
support
the
square-bracketed
CURIE
syntax
as
the
mechanism
is
not
required
to
disambiguate
IRI
s
in
a
JSON-LD
document
like
it
is
in
HTML
documents.
4.5
Automatic
Typing
Since
JSON
is
capable
of
expressing
typed
information
such
as
doubles,
integers,
and
boolean
values.
As
demonstrated
below,
JSON-LD
utilizes
that
information
to
create
typed
literal
s:
  {
  ...
    // The following two values are automatically converted to a type of xsd:double
    // and both values are equivalent to each other.
    &quot;measure:cups&quot;: ,
    &quot;measure:cups&quot;: ,
    // The following value is automatically converted to a type of xsd:double as well
    &quot;space:astronomicUnits&quot;: ,
    // The following value should never be converted to a language-native type
    &quot;measure:stones&quot;: ,
    // This value is automatically converted to having a type of xsd:integer
    &quot;chem:protons&quot;: ,
    // This value is automatically converted to having a type of xsd:boolean
    &quot;sensor:active&quot;: ,
  ...
}
When
dealing
with
a
number
of
modern
programming
languages,
including
JavaScript
ECMA-262,
there
is
no
distinction
between
xsd:decimal
and
xsd:double
values.
That
is,
the
number
5.3
and
the
number
5.3e0
are
treated
as
if
they
were
the
same.
When
converting
from
JSON-LD
to
a
language-native
format
and
back,
datatype
information
is
lost
in
a
number
of
these
languages.
Thus,
one
could
say
that
5.3
is
a
xsd:decimal
and
5.3e0
is
an
xsd:double
in
JSON-LD,
but
when
both
values
are
converted
to
a
language-native
format
the
datatype
difference
between
the
two
is
lost
because
the
machine-level
representation
will
almost
always
be
a
double
.
Implementers
should
be
aware
of
this
potential
round-tripping
issue
between
xsd:decimal
and
xsd:double
.
Specifically
objects
with
a
datatype
of
xsd:decimal
must
not
be
converted
to
a
language
native
type.
4.6
Type
Coercion
JSON-LD
supports
the
coercion
of
values
to
particular
data
types.
Type
coercion
allows
someone
deploying
JSON-LD
to
coerce
the
incoming
or
outgoing
types
to
the
proper
data
type
based
on
a
mapping
of
data
type
IRI
s
to
property
types.
Using
type
coercion,
one
may
convert
simple
JSON
data
to
properly
typed
RDF
data.
The
example
below
demonstrates
how
a
JSON-LD
author
can
coerce
values
to
plain
literal
s,
typed
literal
s
and
IRIs.
  {
    &quot;@context&quot;:
    {
       &quot;rdf&quot;: &quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;,
       &quot;xsd&quot;: &quot;http://www.w3.org/2001/XMLSchema#&quot;,
       &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
       &quot;age&quot;: &quot;http://xmlns.com/foaf/0.1/age&quot;,
       &quot;homepage&quot;: &quot;http://xmlns.com/foaf/0.1/homepage&quot;,
       &quot;@coerce&quot;:
       {
          &quot;xsd:integer&quot;: &quot;age&quot;,
          &quot;@iri&quot;: &quot;homepage&quot;
       }
    },
    &quot;name&quot;: &quot;John Smith&quot;,
    &quot;age&quot;: ,
    &quot;homepage&quot;: 
}
The
example
above
would
generate
the
following
triples:
  _:bnode1
     &lt;http://xmlns.com/foaf/0.1/name&gt;
        &quot;John Smith&quot; .
  _:bnode1
     &lt;http://xmlns.com/foaf/0.1/age&gt;
        &quot;41&quot;^^http://www.w3.org/2001/XMLSchema#integer .
  _:bnode1
     &lt;http://xmlns.com/foaf/0.1/homepage&gt;
&lt;http://example.org/home/&gt;
.
The
mechanism
for
type
coercion
is
still
being
debated.
It
may
be
that
the
key/value
positions
are
swapped,
yielding
a
@context
such
as
the
following:
  {
    &quot;@context&quot;: {
      &quot;rdf&quot;: &quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;,
      &quot;xsd&quot;: &quot;http://www.w3.org/2001/XMLSchema#&quot;,
      &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
      &quot;age&quot;: &quot;http://xmlns.com/foaf/0.1/age&quot;,
      &quot;homepage&quot;: &quot;http://xmlns.com/foaf/0.1/homepage&quot;,
      &quot;currentProject&quot;: &quot;http://xmlns.com/foaf/0.1/currentProject&quot;,
      &quot;@coerce&quot;: {
        &quot;age&quot;: &quot;xsd:integer&quot;,
        &quot;homepage&quot;: &quot;@iri&quot;,
        &quot;currentProject&quot;: [&quot;@iri&quot;, &quot;@list&quot;]
       }
    },
    ...
}
An
alternative
is
to
merge
the
coercion
into
term
definitions:
  {
    &quot;@context&quot;:
    {
      &quot;rdf&quot;: &quot;http://www.w3.org/1999/02/22-rdf-syntax-ns#&quot;,
      &quot;xsd&quot;: &quot;http://www.w3.org/2001/XMLSchema#&quot;,
      &quot;name&quot;: &quot;http://xmlns.com/foaf/0.1/name&quot;,
      &quot;age&quot;: ,
      &quot;homepage&quot;: ,
      &quot;currentProject&quot;: ,
    },
    ...
}
4.7
Chaining
Object
chaining
is
a
JSON-LD
feature
that
allows
an
author
to
use
the
definition
of
JSON-LD
objects
as
property
values.
This
is
a
commonly
used
mechanism
for
creating
a
parent-child
relationship
between
two
subject
s.
The
example
shows
an
two
subjects
related
by
a
property
from
the
first
subject:
    {
  ...
    &quot;name&quot;: &quot;Manu Sporny&quot;,
    &quot;&quot;: {
      &quot;&quot;,
      &quot;&quot;,
    }
  ...
}
An
object
definition,
like
the
one
used
above,
may
be
used
as
a
JSON
value
at
any
point
in
JSON-LD.
4.8
Identifying
Unlabeled
Nodes
At
times,
it
becomes
necessary
to
be
able
to
express
information
without
being
able
to
specify
the
subject.
Typically,
this
type
of
node
is
called
an
unlabeled
node
or
a
blank
node.
In
JSON-LD,
unlabeled
node
identifiers
are
automatically
created
if
a
subject
is
not
specified
using
the
@subject
keyword.
However,
authors
may
provide
identifiers
for
unlabeled
nodes
by
using
the
special
_
(underscore)
prefix
.
This
allows
to
reference
the
node
locally
within
the
document
but
not
in
an
external
document.
  {
  ...
    &quot;@subject&quot;: &quot;&quot;,
  ...
}
The
example
above
would
set
the
subject
to
_:foo
,
which
can
then
be
used
later
on
in
the
JSON-LD
markup
to
refer
back
to
the
unlabeled
node.
This
practice,
however,
is
usually
frowned
upon
when
generating
Linked
Data
.
If
a
developer
finds
that
they
refer
to
the
unlabeled
node
more
than
once,
they
should
consider
naming
the
node
using
a
resolve-able
IRI
.
4.9
Aliasing
Keywords
JSON-LD
allows
all
of
the
syntax
keywords,
except
for
@context
,
to
be
aliased.
This
feature
allows
more
legacy
JSON
content
to
be
supported
by
JSON-LD.
It
also
allows
developers
to
design
domain-specific
implementations
using
only
the
JSON-LD
context
.
  {
    &quot;@context&quot;:
    {
       ,
       ,
       &quot;name&quot;: &quot;http://schema.org/name&quot;
    },
    &quot;url&quot;: &quot;http://example.com/about#gregg&quot;,
    &quot;a&quot;: &quot;http://schema.org/Person&quot;,
    &quot;name&quot;: &quot;Gregg Kellogg&quot;
}
In
the
example
above,
the
@subject
and
@type
keywords
have
been
given
the
aliases
url
and
a
,
respectively.
5.
Using
JSON-LD
for
RDF
JSON-LD
is
a
specification
for
representing
Linked
Data
in
JSON.
A
common
way
of
working
with
Linked
Data
is
through
RDF
,
the
Resource
Description
Framework.
RDF
can
be
expressed
using
JSON-LD
by
associating
JSON-LD
concepts
such
as
@subject
and
@type
with
the
equivalent
IRI
s
in
RDF.
Further
information
about
RDF
may
be
found
in
[
RDF-PRIMER
].
Some
examples
of
encoding
RDF
into
JSON-LD
may
be
found
in
Appendix
A
.
Details
of
transforming
JSON-LD
into
RDF
are
defined
in
[
JSON-LD-API
].
A.
Markup
Examples
The
JSON-LD
markup
examples
below
demonstrate
how
JSON-LD
can
be
used
to
express
semantic
data
marked
up
in
other
languages
such
as
RDFa,
Microformats,
and
Microdata.
These
sections
are
merely
provided
as
proof
that
JSON-LD
is
very
flexible
in
what
it
can
express
across
different
Linked
Data
approaches.
A.1
Turtle
The
following
are
examples
of
representing
RDF
as
expressed
in
[
TURTLE
]
into
JSON-LD.
A.1.1
Prefix
and
Base
definitions
The
JSON-LD
context
has
direct
equivalents
for
Turtle
@base
and
@prefix
expressions:
  @base &lt;http://manu.sporny.org/&gt; .
  @prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
  &lt;#me&gt; a foaf:Person;
    foaf:name &quot;Manu Sporny&quot;;
foaf:homepage
&lt;&gt;
.
  {
    &quot;@context&quot;: {
      &quot;@base&quot;:  &quot;http://manu.sporny.org/&quot;,
      &quot;foaf&quot;:   &quot;http://xmlns.com/foaf/0.1/&quot;
    },
    &quot;@subject&quot;:       &quot;#me&quot;,
    &quot;@type&quot;:          &quot;foaf:Person&quot;,
    &quot;foaf:name&quot;:      &quot;Manu Sporny&quot;,
    &quot;foaf:homepage&quot;:  {&quot;@iri&quot;: &quot;&quot;}
}
A.1.2
Chaining
Both
Turtle
and
JSON-LD
allow
chaining
of
objects,
although
Turtle
only
allows
chaining
of
objects
which
use
nlank
node
identifiers.
  @base &lt;http://manu.sporny.org/&gt; .
  @prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
  &lt;#me&gt; a foaf:Person;
    foaf:name &quot;Manu Sporny&quot;;
foaf:knows
[
a
foaf:Person;
foaf:name
&quot;Gregg
Kellogg&quot;
]
.
  {
    &quot;@context&quot;: {
      &quot;@base&quot;:  &quot;http://manu.sporny.org/&quot;,
      &quot;foaf&quot;:   &quot;http://xmlns.com/foaf/0.1/&quot;
    },
    &quot;@subject&quot;:       &quot;#me&quot;,
    &quot;@type&quot;:          &quot;foaf:Person&quot;,
    &quot;foaf:name&quot;:      &quot;Manu Sporny&quot;,
    &quot;foaf:knows&quot;:  {
      &quot;@type&quot;:          &quot;foaf:Person&quot;,
      &quot;foaf:name&quot;:      &quot;Gregg Kellogg&quot;
    }
}
A.1.3
Lists
Both
JSON-LD
and
Turtle
can
represent
sequential
lists
of
values.
  @prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt; .
  &lt;http://example.org/people#joebob&gt; a foaf:Person;
    foaf:name &quot;Joe Bob&quot;;
foaf:nick
(
&quot;joe&quot;
&quot;bob&quot;
&quot;jaybee&quot;)
.
  {
    &quot;@context&quot;: {
      &quot;@base&quot;:  &quot;http://manu.sporny.org/&quot;,
      &quot;foaf&quot;:   &quot;http://xmlns.com/foaf/0.1/&quot;
    },
    &quot;@subject&quot;:       &quot;http://example.org/people#joebob&quot;,
    &quot;@type&quot;:          &quot;foaf:Person&quot;,
    &quot;foaf:name&quot;:      &quot;Joe Bob&quot;,
    &quot;foaf:nick&quot;:      {&quot;@list&quot;: [&quot;joe&quot;, &quot;bob&quot;, &quot;jaybe&quot;]}
}
A.2
RDFa
The
following
example
describes
three
people
with
their
respective
names
and
homepages.
  &gt;
     &lt;ul&gt;
        &lt;li &gt;
          &lt;a &gt;Bob&lt;/a&gt;
        &lt;/li&gt;
        &lt;li &gt;
          &lt;a &gt;Eve&lt;/a&gt;
        &lt;/li&gt;
        &lt;li &gt;
          &lt;a &gt;Manu&lt;/a&gt;
        &lt;/li&gt;
     &lt;/ul&gt;
&lt;/div&gt;
An
example
JSON-LD
implementation
is
described
below,
however,
there
are
other
ways
to
mark-up
this
information
such
that
the
context
is
not
repeated.
  {
    &quot;@context&quot;: { &quot;foaf&quot;: &quot;http://xmlns.com/foaf/0.1/&quot;},
    &quot;@subject&quot;: [
     {
       &quot;@subject&quot;: &quot;_:bnode1&quot;,
       &quot;@type&quot;: &quot;foaf:Person&quot;,
       &quot;foaf:homepage&quot;: &quot;http://example.com/bob/&quot;,
       &quot;foaf:name&quot;: &quot;Bob&quot;
     },
     {
       &quot;@subject&quot;: &quot;_:bnode2&quot;,
       &quot;@type&quot;: &quot;foaf:Person&quot;,
       &quot;foaf:homepage&quot;: &quot;http://example.com/eve/&quot;,
       &quot;foaf:name&quot;: &quot;Eve&quot;
     },
     {
       &quot;@subject&quot;: &quot;_:bnode3&quot;,
       &quot;@type&quot;: &quot;foaf:Person&quot;,
       &quot;foaf:homepage&quot;: &quot;http://example.com/manu/&quot;,
       &quot;foaf:name&quot;: &quot;Manu&quot;
     }
    ]
}
A.3
Microformats
The
following
example
uses
a
simple
Microformats
hCard
example
to
express
how
the
Microformat
is
represented
in
JSON-LD.
  &lt;div class=&quot;vcard&quot;&gt;
   &lt;a class=&quot;url fn&quot; href=&quot;http://tantek.com/&quot;&gt;Tantek Çelik&lt;/a&gt;
&lt;/div&gt;
The
representation
of
the
hCard
expresses
the
Microformat
terms
in
the
context
and
uses
them
directly
for
the
url
and
fn
properties.
Also
note
that
the
Microformat
to
JSON-LD
processor
has
generated
the
proper
URL
type
for
http://tantek.com
.
  {
    &quot;@context&quot;:
    {
      &quot;vcard&quot;: &quot;http://microformats.org/profile/hcard#vcard&quot;,
      &quot;url&quot;: &quot;http://microformats.org/profile/hcard#url&quot;,
      &quot;fn&quot;: &quot;http://microformats.org/profile/hcard#fn&quot;,
      &quot;@coerce&quot;: { &quot;@iri&quot;: &quot;url&quot; }
    },
    &quot;@subject&quot;: &quot;_:bnode1&quot;,
    &quot;@type&quot;: &quot;vcard&quot;,
    &quot;url&quot;: &quot;http://tantek.com/&quot;,
    &quot;fn&quot;: &quot;Tantek Çelik&quot;
}
A.4
Microdata
The
Microdata
example
below
expresses
book
information
as
a
Microdata
Work
item.
  &lt;dl itemscope
      itemtype=&quot;http://purl.org/vocab/frbr/core#Work&quot;
      itemid=&quot;http://purl.oreilly.com/works/45U8QJGZSQKDH8N&quot;&gt;
   &lt;dt&gt;Title&lt;/dt&gt;
   &lt;dd&gt;&lt;cite itemprop=&quot;http://purl.org/dc/terms/title&quot;&gt;Just a Geek&lt;/cite&gt;&lt;/dd&gt;
   &lt;dt&gt;By&lt;/dt&gt;
   &lt;dd&gt;&lt;span itemprop=&quot;http://purl.org/dc/terms/creator&quot;&gt;Wil Wheaton&lt;/span&gt;&lt;/dd&gt;
   &lt;dt&gt;Format&lt;/dt&gt;
   &lt;dd itemprop=&quot;http://purl.org/vocab/frbr/core#realization&quot;
       itemscope
       itemtype=&quot;http://purl.org/vocab/frbr/core#Expression&quot;
       itemid=&quot;http://purl.oreilly.com/products/9780596007683.BOOK&quot;&gt;
    &lt;link itemprop=&quot;http://purl.org/dc/terms/type&quot; href=&quot;http://purl.oreilly.com/product-types/BOOK&quot;&gt;
    Print
   &lt;/dd&gt;
   &lt;dd itemprop=&quot;http://purl.org/vocab/frbr/core#realization&quot;
       itemscope
       itemtype=&quot;http://purl.org/vocab/frbr/core#Expression&quot;
       itemid=&quot;http://purl.oreilly.com/products/9780596802189.EBOOK&quot;&gt;
    &lt;link itemprop=&quot;http://purl.org/dc/terms/type&quot; href=&quot;http://purl.oreilly.com/product-types/EBOOK&quot;&gt;
    Ebook
   &lt;/dd&gt;
&lt;/dl&gt;
Note
that
the
JSON-LD
representation
of
the
Microdata
information
stays
true
to
the
desires
of
the
Microdata
community
to
avoid
contexts
and
instead
refer
to
items
by
their
full
IRI
.
  [
    {
      &quot;@subject&quot;: &quot;http://purl.oreilly.com/works/45U8QJGZSQKDH8N&quot;,
      &quot;@type&quot;: &quot;http://purl.org/vocab/frbr/core#Work&quot;,
      &quot;http://purl.org/dc/terms/title&quot;: &quot;Just a Geek&quot;,
      &quot;http://purl.org/dc/terms/creator&quot;: &quot;Whil Wheaton&quot;,
      &quot;http://purl.org/vocab/frbr/core#realization&quot;:
        [&quot;http://purl.oreilly.com/products/9780596007683.BOOK&quot;, &quot;http://purl.oreilly.com/products/9780596802189.EBOOK&quot;]
    },
    {
      &quot;@subject&quot;: &quot;http://purl.oreilly.com/products/9780596007683.BOOK&quot;,
      &quot;@type&quot;: &quot;http://purl.org/vocab/frbr/core#Expression&quot;,
      &quot;http://purl.org/dc/terms/type&quot;: &quot;http://purl.oreilly.com/product-types/BOOK&quot;
    },
    {
      &quot;@subject&quot;: &quot;http://purl.oreilly.com/products/9780596802189.EBOOK&quot;,
      &quot;@type&quot;: &quot;http://purl.org/vocab/frbr/core#Expression&quot;,
      &quot;http://purl.org/dc/terms/type&quot;: &quot;http://purl.oreilly.com/product-types/EBOOK&quot;
    }
]
</del>
<div class="appendix section" id="mashing-up-vocabularies">
<h2>
<span class="secno">
<del class="diff-old">B.
</del>
<ins class="diff-chg">C.
</ins>
</span>
Mashing
Up
Vocabularies
</h2>
<p>
Developers
would
also
benefit
by
allowing
other
vocabularies
to
be
used
automatically
with
their
JSON
API.
There
are
over
200
<a class="tref internalDFN" title="web_vocabulary" href="#dfn-web_vocabulary">
Web
Vocabulary
</a>
Documents
that
are
available
for
use
on
the
Web
today.
Some
of
these
vocabularies
are:
</p>
<ul>
<li>
RDF
-
for
describing
information
about
objects
and
concepts
on
the
Web.
</li>
<li>
RDFS
-
for
expressing
things
like
labels
and
comments.
</li>
<li>
XSD
-
for
specifying
basic
types
like
strings,
integers,
dates
and
times.
</li>
<li>
Dublin
Core
-
for
describing
creative
works.
</li>
<li>
FOAF
-
for
describing
social
networks.
</li>
<li>
Calendar
-
for
specifying
events.
</li>
<li>
SIOC
-
for
describing
discussions
on
blogs
and
websites.
</li>
<li>
CCrel
-
for
describing
Creative
Commons
and
other
types
of
licenses.
</li>
<li>
GEO
-
for
describing
geographic
location.
</li>
<li>
VCard
-
for
describing
organizations
and
people.
</li>
<li>
DOAP
-
for
describing
projects.
</li>
</ul>
<p>
You
can
use
these
vocabularies
in
combination,
like
so:
</p>
<del class="diff-old">  {
    &quot;&quot;,
    &quot;&quot;: &quot;Manu Sporny&quot;,
    &quot;&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;
</del>
<pre class="example">{
<ins class="diff-chg">  "<span class="diff">@type</span>": "<span class="diff">foaf:Person</span>",
  "<span class="diff">foaf:name</span>": "Manu Sporny",
  "<span class="diff">foaf:homepage</span>": "http://manu.sporny.org/",
  "<span class="diff">sioc:avatar</span>": "http://twitter.com/account/profile_image/manusporny"
</ins>
}
</pre>
<p>
Developers
can
also
specify
their
own
Vocabulary
documents
by
modifying
the
<a class="tref internalDFN" title="active_context" href="#dfn-active_context">
active
context
</a>
in-line
using
the
<code>
@context
</code>
keyword,
like
so:
</p>
<del class="diff-old">  {
    ,
    &quot;@type&quot;: &quot;foaf:Person&quot;,
    &quot;foaf:name&quot;: &quot;Manu Sporny&quot;,
    &quot;foaf:homepage&quot;: &quot;http://manu.sporny.org/&quot;,
    &quot;sioc:avatar&quot;: &quot;http://twitter.com/account/profile_image/manusporny&quot;,
    &quot;myvocab:personality&quot;: &quot;friendly&quot;
</del>
<pre class="example">{
  <span class="diff">"@context": { "myvocab": "http://example.org/myvocab#" }</span>,
<ins class="diff-chg">  "@type": "foaf:Person",
  "foaf:name": "Manu Sporny",
  "foaf:homepage": "http://manu.sporny.org/",
  "sioc:avatar": "http://twitter.com/account/profile_image/manusporny"<span class="diff">,
  "myvocab:personality": "friendly"</span>
</ins>
}
</pre>
<p>
The
<code>
@context
</code>
keyword
is
used
to
change
how
the
JSON-LD
processor
evaluates
key-value
pairs.
In
this
case,
it
was
used
to
map
one
string
('myvocab')
to
another
string,
which
is
interpreted
as
a
<a class="tref internalDFN" title="iri" href="#dfn-iri">
<abbr title="Internationalized Resource Identifier">
IRI
</abbr>
</a>.
In
the
example
above,
the
<code>
myvocab
</code>
string
is
replaced
with
<del class="diff-old">&quot;
</del>
<ins class="diff-chg">"
</ins>
<code>
http://example.org/myvocab#
</code>
<del class="diff-old">&quot;
</del>
<ins class="diff-chg">"
</ins>
when
it
is
detected.
In
the
example
above,
<del class="diff-old">&quot;
</del>
<ins class="diff-chg">"
</ins>
<code>
myvocab:personality
</code>
<del class="diff-old">&quot;
</del>
<ins class="diff-chg">"
</ins>
would
expand
to
<del class="diff-old">&quot;
</del>
<ins class="diff-chg">"
</ins>
<code>
http://example.org/myvocab#personality
</code>
<del class="diff-old">&quot;.
</del>
<ins class="diff-chg">".
</ins>
</p>
<p>
This
mechanism
is
a
short-hand,
called
a
<a class="tref internalDFN" title="web_vocabulary" href="#dfn-web_vocabulary">
Web
Vocabulary
</a>
<a class="tref internalDFN" title="prefix" href="#dfn-prefix">
prefix
</a>,
and
provides
developers
an
unambiguous
way
to
map
any
JSON
value
to
RDF.
</p>
</div>
<div class="appendix section" id="iana-considerations">
<h2>
<span class="secno">
<del class="diff-old">C.
</del>
<ins class="diff-chg">D.
</ins>
</span>
IANA
Considerations
</h2>
<p>
This
section
is
included
merely
for
standards
community
review
and
will
be
submitted
to
the
Internet
Engineering
Steering
Group
if
this
specification
becomes
a
W3C
Recommendation.
</p>
<dl>
<dt>
Type
name:
</dt>
<dd>
application
</dd>
<dt>
Subtype
name:
</dt>
<dd>
ld+json
</dd>
<dt>
Required
parameters:
</dt>
<dd>
None
</dd>
<dt>
Optional
parameters:
</dt>
<dd>
<dl>
<dt>
<code>
form
</code>
</dt>
<dd>
Determines
the
serialization
form
for
the
JSON-LD
document.
Valid
values
include;
<code>
compacted
</code>,
<code>
expanded
</code>,
<del class="diff-old">framed
,
</del>
and
<code>
normalized
</code>.
<del class="diff-old">Other
values
are
allowed,
but
must
be
pre-pended
with
a
x-
string
until
they
are
clearly
defined
by
a
stable
specification.
</del>
If
no
form
is
specified
in
an
HTTP
request
header
to
a
responding
application,
such
as
a
Web
server,
the
application
<em class="rfc2119" title="may">
may
</em>
choose
any
form.
If
no
form
is
specified
for
a
receiving
application,
the
form
<em class="rfc2119" title="must not">
must
not
</em>
be
assumed
to
take
any
particular
form.
</dd>
<del class="diff-old">It
is
currently
being
discussed
to
remove
form=framed
from
this
specification
as
there
are
several
issues
with
it.
</del>
</dl>
</dd>
<dt>
Encoding
considerations:
</dt>
<dd>
The
same
as
the
<code>
application/json
</code>
MIME
media
type.
</dd>
<dt>
Security
considerations:
</dt>
<dd>
Since
JSON-LD
is
intended
to
be
a
pure
data
exchange
format
for
directed
graphs,
the
serialization
<em class="rfc2119" title="should not">
should
not
</em>
be
passed
through
a
code
execution
mechanism
such
as
JavaScript's
<code>
eval()
</code>
function.
It
is
<em class="rfc2119" title="recommended">
recommended
</em>
that
a
conforming
parser
does
not
attempt
to
directly
evaluate
the
JSON-LD
serialization
and
instead
purely
parse
the
input
into
a
language-native
data
structure.
</dd>
<dt>
Interoperability
considerations:
</dt>
<dd>
Not
Applicable
</dd>
<dt>
Published
specification:
</dt>
<dd>
The
<a href="http://json-ld/spec/latest/">
JSON-LD
</a>
specification.
</dd>
<dt>
Applications
that
use
this
media
type:
</dt>
<dd>
Any
programming
environment
that
requires
the
exchange
of
directed
graphs.
Implementations
of
JSON-LD
have
been
created
for
JavaScript,
Python,
Ruby,
PHP
and
C++.
</dd>
<dt>
Additional
information:
</dt>
<dd>
<dl>
<dt>
Magic
number(s):
</dt>
<dd>
Not
Applicable
</dd>
<dt>
File
extension(s):
</dt>
<dd>.jsonld
</dd>
<dt>
Macintosh
file
type
code(s):
</dt>
<dd>
TEXT
</dd>
</dl>
</dd>
<dt>
Person
&amp;
email
address
to
contact
for
further
information:
</dt>
<dd>
Manu
Sporny
&lt;msporny@digitalbazaar.com&gt;
</dd>
<dt>
Intended
usage:
</dt>
<dd>
Common
</dd>
<dt>
Restrictions
on
usage:
</dt>
<dd>
None
</dd>
<dt>
Author(s):
</dt>
<dd>
Manu
Sporny,
Gregg
Kellogg,
Dave
Longley
</dd>
<dt>
Change
controller:
</dt>
<dd>
W3C
</dd>
</dl>
</div>
<div class="appendix section" id="acknowledgements">
<h2>
<span class="secno">
<del class="diff-old">D.
</del>
<ins class="diff-chg">E.
</ins>
</span>
Acknowledgements
</h2>
<p>
The
editors
would
like
to
thank
Mark
Birbeck,
who
provided
a
great
deal
of
the
initial
push
behind
the
JSON-LD
work
via
his
work
on
RDFj,
Dave
Longley,
Dave
Lehn
and
Mike
Johnson
who
reviewed,
provided
feedback,
and
performed
several
implementations
of
the
specification,
and
Ian
Davis,
who
created
RDF/JSON.
Thanks
also
to
Nathan
Rixham,
Bradley
P.
Allen,
Kingsley
Idehen,
Glenn
McDonald,
Alexandre
Passant,
Danny
Ayers,
Ted
Thibodeau
Jr.,
Olivier
Grisel,
Niklas
<del class="diff-old">Lindström,
</del>
<ins class="diff-chg">Lindstr�m,
</ins>
Markus
Lanthaler,
and
Richard
Cyganiak
for
their
input
on
the
specification.
</p>
</div>
<div id="references" class="appendix section">
<h2>
<span class="secno">
<del class="diff-old">E.
</del>
<ins class="diff-chg">F.
</ins>
</span>
References
</h2>
<div id="normative-references" class="section">
<h3>
<span class="secno">
<del class="diff-old">E.1
</del>
<ins class="diff-chg">F.1
</ins>
</span>
Normative
references
</h3>
<dl class="bibliography">
<dt id="bib-BCP47">
[BCP47]
</dt>
<dd>
A.
Phillips,
M.
Davis.
<a href="http://tools.ietf.org/rfc/bcp/bcp47.txt">
<cite>
Tags
for
Identifying
Languages
</cite>
</a>
September
2009.
IETF
Best
Current
Practice.
URL:
<a href="http://tools.ietf.org/rfc/bcp/bcp47.txt">
http://tools.ietf.org/rfc/bcp/bcp47.txt
</a>
</dd>
<del class="diff-old">[RDF-CONCEPTS]
Graham
Klyne;
Jeremy
J.
Carroll.
Resource
Description
Framework
(RDF):
Concepts
and
Abstract
Syntax.
10
February
2004.
W3C
Recommendation.
URL:
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210
</del>
<dt id="bib-RFC3987">
[RFC3987]
</dt>
<dd>
M.
<del class="diff-old">Dürst;
</del>
<ins class="diff-chg">D�rst;
</ins>
M.
Suignard.
<a href="http://www.ietf.org/rfc/rfc3987.txt">
<cite>
Internationalized
Resource
Identifiers
(IRIs).
</cite>
</a>
January
2005.
Internet
RFC
3987.
URL:
<a href="http://www.ietf.org/rfc/rfc3987.txt">
http://www.ietf.org/rfc/rfc3987.txt
</a>
</dd>
<dt id="bib-RFC4627">
[RFC4627]
</dt>
<dd>
D.
Crockford.
<a href="http://www.ietf.org/rfc/rfc4627.txt">
<cite>
The
application/json
Media
Type
for
JavaScript
Object
Notation
(JSON)
</cite>
</a>
July
2006.
Internet
RFC
4627.
URL:
<a href="http://www.ietf.org/rfc/rfc4627.txt">
http://www.ietf.org/rfc/rfc4627.txt
</a>
</dd>
<dt id="bib-WEBIDL">
[WEBIDL]
</dt>
<dd>
Cameron
McCormack.
<a href="http://www.w3.org/TR/2011/WD-WebIDL-20110927/">
<cite>
Web
IDL.
</cite>
</a>
<del class="diff-old">19
December
2008.
</del>
<ins class="diff-chg">27
September
2011.
</ins>
W3C
Working
Draft.
(Work
in
progress.)
URL:
<del class="diff-old">http://www.w3.org/TR/2008/WD-WebIDL-20081219
</del>
<a href="http://www.w3.org/TR/2011/WD-WebIDL-20110927/">
<ins class="diff-chg">http://www.w3.org/TR/2011/WD-WebIDL-20110927/
</ins>
</a>
</dd>
</dl>
</div>
<div id="informative-references" class="section">
<h3>
<span class="secno">
<del class="diff-old">E.2
</del>
<ins class="diff-chg">F.2
</ins>
</span>
Informative
references
</h3>
<dl class="bibliography">
<dt id="bib-ECMA-262">
[ECMA-262]
</dt>
<dd>
<a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">
<cite>
ECMAScript
Language
<del class="diff-old">Specification,
Third
Edition.
</del>
<ins class="diff-chg">Specification.
</ins>
</cite>
</a>
December
1999.
URL:
<a href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">
http://www.ecma-international.org/publications/standards/Ecma-262.htm
</a>
</dd>
<dt id="bib-HTML-RDFA">
[HTML-RDFA]
</dt>
<dd>
Manu
Sporny;
et
al.
<a href="http://www.w3.org/TR/rdfa-in-html/">
<cite>
HTML+RDFa
</cite>
</a>
04
March
2010.
W3C
Working
Draft.
URL:
<a href="http://www.w3.org/TR/rdfa-in-html/">
http://www.w3.org/TR/rdfa-in-html/
</a>
</dd>
<dt id="bib-JSON-LD-API">
[JSON-LD-API]
</dt>
<dd>
Manu
Sporny,
Gregg
Kellogg,
Dave
Longley,
Eds.
<cite>
<a href="http://json-ld.org/spec/latest/json-ld-api/">
JSON-LD
API
</a>
</cite>
Latest.
W3C
Editor's
Draft.
URL:
<a href="http://json-ld.org/spec/latest/json-ld-api/">
<del class="diff-old">http://www.w3.org/2010/02/rdfa/sources/rdf-interfaces/
[MICRODATA]
Ian
Hickson;
et
al.
Microdata
04
March
2010.
W3C
Working
Draft.
URL:
http://www.w3.org/TR/microdata/
[MICROFORMATS]
Microformats
.
URL:
http://microformats.org
</del>
<ins class="diff-chg">http://json-ld.org/spec/latest/json-ld-api/
</ins>
</a>
</dd>
<dt id="bib-RDF-PRIMER">
[RDF-PRIMER]
</dt>
<dd>
Frank
Manola;
Eric
Miller.
<a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">
<cite>
RDF
Primer.
</cite>
</a>
10
February
2004.
W3C
Recommendation.
URL:
<a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">
http://www.w3.org/TR/2004/REC-rdf-primer-20040210/
</a>
</dd>
<del class="diff-old">[RDF-SCHEMA]
Dan
Brickley;
Ramanathan
V.
Guha.
RDF
Vocabulary
Description
Language
1.0:
RDF
Schema.
10
February
2004.
W3C
Recommendation.
URL:
http://www.w3.org/TR/2004/REC-rdf-schema-20040210
</del>
<dt id="bib-RDFA-CORE">
[RDFA-CORE]
</dt>
<dd>
Shane
McCarron;
et
al.
<a href="http://www.w3.org/TR/2011/WD-rdfa-core-20111215">
<cite>
RDFa
Core
1.1:
Syntax
and
processing
rules
for
embedding
RDF
through
attributes.
</cite>
</a>
<del class="diff-old">31
March
</del>
<ins class="diff-chg">15
December
</ins>
2011.
W3C
Working
Draft.
URL:
<del class="diff-old">http://www.w3.org/TR/2011/WD-rdfa-core-20110331
[RFC3986]
T.
Berners-Lee;
R.
Fielding;
L.
Masinter.
Uniform
Resource
Identifier
(URI):
Generic
Syntax.
January
2005.
Internet
RFC
3986.
URL:
http://www.ietf.org/rfc/rfc3986.txt
</del>
<a href="http://www.w3.org/TR/2011/WD-rdfa-core-20111215">
<ins class="diff-chg">http://www.w3.org/TR/2011/WD-rdfa-core-20111215
</ins>
</a>
</dd>
<dt id="bib-TURTLE">
[TURTLE]
</dt>
<dd>
David
Beckett,
Tim
Berners-Lee.
<a href="http://www.w3.org/TeamSubmission/turtle/">
<cite>
Turtle:
Terse
RDF
Triple
Language.
</cite>
</a>
January
2008.
W3C
Team
Submission.
URL:
<a href="http://www.w3.org/TeamSubmission/turtle/">
http://www.w3.org/TeamSubmission/turtle/
</a>
</dd>
<del class="diff-old">2011.
W3C
Working
Draft.
URL:
http://www.w3.org/TR/2011/WD-rdfa-core-20110331
[RFC3986]
T.
Berners-Lee;
R.
Fielding;
L.
Masinter.
Uniform
Resource
Identifier
(URI):
Generic
Syntax.
January
2005.
Internet
RFC
3986.
URL:
http://www.ietf.org/rfc/rfc3986.txt
[TURTLE]
</del>
<dt id="bib-XML-NAMES">
<ins class="diff-chg">[XML-NAMES]
</ins>
</dt>
<dd>
<del class="diff-old">David
Beckett,
Tim
Berners-Lee.
</del>
<ins class="diff-chg">Richard
Tobin;
et
al.
</ins><a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/">
<cite>
<del class="diff-old">Turtle:
Terse
RDF
Triple
Language.
</del>
<ins class="diff-chg">Namespaces
in
XML
1.0
(Third
Edition).
</ins>
</cite>
</a>
<del class="diff-old">January
2008.
</del>
<ins class="diff-chg">8
December
2009.
</ins>
W3C
<del class="diff-old">Team
Submission.
</del>
<ins class="diff-chg">Recommendation.
</ins>
URL:
<del class="diff-old">http://www.w3.org/TeamSubmission/turtle/
</del>
<a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/">
<ins class="diff-chg">http://www.w3.org/TR/2009/REC-xml-names-20091208/
</ins>
</a>
</dd>
</dl>
</div>
</div>
</body>
</html>